Стоит RH Linux 7.3, ядро 2.4.19. , до установки патча стоял Oracle 8.1.7.0.1 с установленным патчем 8.1.7.3.

Изменения:
До установки патча, мог запустить от 1 до 10 процессов записи в базу (dbw0-dbw9), согласно Oracle 8i Reference.

После установки патча обратил на особенность, что теперь максимальное кол-во этих процессов зависит от значения параметра db_block_lru_latches.
Т.е если db_writer_processes=10, реально кол-во запущенных процессов определяется db_block_lru_latches.

Максимальное же число защёлок определяется по формуле max(db_block_lru_latches) = CPU_COUNT x 2 x 3.

Так как у меня один процессор, то максимально могу запустить 6 процессов.

Мне кажется это странным. Кто знает что-то по этому вопросу - пишите.

Предназначение параметров я вообще говоря знаю.

Между тем я констатирую факт, что после применения патча максимальное кол-во процессов теперь определяется по другому.

"(DBWR обычно ставят равным, но не больше кол-вa CPU)"

Можно источник?

Опыт и эксперименты вещь конечно хорошая, однако не плохо ссылки иметь на подтверждение, которые декларирует сам Oracle.

Привожу текст из книги Oracle8 Настройка. Майкл Дж. Кори итд, Oracle Press:
"....Некоторые администраторы заблуждаются, думая что это значение ограничивается числом ЦП, с которыми работают процессы. Это не так. Значение соответсвующего элемента файла параметров инициализации должно быть основано на количестве файлов данных, существующих в базе. Рекомендуется устанавливать параметр db_writerers равным двукратному числу файлов базы данных".

"Вот сейчас у меня около 20 файлов в базе, а ведь есть и такие где сотни файлов."

По доке их максимум только 10 процессов может быть. Так что если более 5 файлов, то без разницы. У меня на 2-процессорной используется 10 процессов. Причём по статистике все процессы используются.

Вообще конечно книга уже устаревшая. В доке по 8i советуют конечно не так. А например если используется три буфера данных(KEEP,RECYCLE,DEFAULT), то по процессу на каждый буфер.

Замечу, что всё равно это из источников хоть каких-то.
Советовать только исходя из своего опыты не совсем правильно, необходимо документальное подтверждение

Честно, скажу что не хочу ввязываться в спор. Согласен любая теория подтверждается на практике. И иногда она не подтверждается. Но я считаю, что если человек в конфе задаёт вопрос, надо информацию давать, которая исходит из родной документации Oracle и из других документальных авторитетных источников. Зная это человек будет это применять, а как получится в его конкретном случае - это уже следствие.
А то некотрые говорят, "на моём опыте так то и так то".
Но ведь базы данных Oracle у каждого очень индивидуальны могут быть. И опыт одной базы может быть совсем неподходящим на другой базе.

По поводу своей базы могу скать, что естественно, что у меня файлы не на одном диске. Потом сегменты откаты, каким процессом по вашему обслуживаются?

"Естественно все процессы используются, не спорю, но они ведь используются не одновременно. Ведь одновременно могут работать только 2 (для 2хCPU). "

Давайте представим, что у меня на одном компе с двумя CPU установлено две базы, скажем SID = ORCL и ORC1.
Для первой базы два процесса, значит и для второй тоже можно два процесса? Так ведь?
Значит по твоей логике одновременно у меня может работать только два процессв DBWR, то есть получается
базы смогут рабоать только попеременно??? Но это же чушь.

Чем принципиально отличается процесс записи Oracle От любого другого процесса любой другой программы? Linux многоздачная система и кол-во одновременно выполняемых процессов не завист от кол-ва процессоров.
Один процессор может выполнять несколько процессов и какая разница это 4 процесса DBWR или 2 процесса DBWR и 2 процесса MySQL?

Всё, я из дисскусии выхожу. Рассматривать и подвергать сомнению основы многозадачности не вижу смысла. Это к Oracle имеет уже второстепенное отношение. Есть конкретные рекомендации по настройке, я стараюсь их придерживаться

А в чём грабли, не можешь поконкретней рассказать?
Я патч поставил на тестовую базу пока только, на рабочую пока не осмелился. Кроме вышеуказанного изменения не наблюдал.

Ну это проблема уже известная. Точнее даже не проблема. Ты установил patch, но не прогнал скрипты. Посмотри, в интрукции указано, как правильно провести апдейт самой базы.

"Вот опять не понял Вашего замечания - какие скрипты я не прогнал? "

Ты инструкцию вообще читал к патчу. Похоже, что нет. Иначе бы ты не спрашивал какие скритпы. А там ведь всё написано. Если нет, приведу её текст. Особенное внимание прошу обратить на:

И на

Я думаю, что прогонка этих скриптов сможет устранить твою проблему. Там написано:

Log in to the oracle account and make sure the environment is set to the correct ORACLE_HOME and ORACLE_SID.
Uncompress and untar the downloaded patch set file into a new directory.
Shut down the existing Oracle Server instance with normal or immediate priority. I.e.: Shutdown all instances (cleanly) if running Parallel Server. Stop all listener, agent and other processes running in or against the ORACLE_HOME to be installed into.
Start the installer:
If the Installer was installed during the installation of the base 8.1.7.0.0 release, then run the installer from within the $ORACLE_HOME/bin directory.
If the Installer was not installed during the installation of the base 8.1.7.0.0 release, then run the installer from within the top-level directory on the base 8.1.7.0.0 CD.
You may install the Patch Set through either an interactive or a silent installation.
To perform an interactive installation using the Oracle Universal Installer graphical interface:
Start the installer from whichever of the above directories is appropriate on your installation:
% ./runInstaller
Follow the steps given below within the installer:
On the Welcome screen, click the Next button. This will display the File Locations screen.
Click the Browse button for the Source... entry field and navigate to the stage directory where you unpacked the Patch Set tar file.
Select the products.jar file. Click the Next button
The products file will be read and the installer will load the product definitions. The products to be loaded will be displayed.
Verify the products listed and then click on the Install button.
Once the installation has completed successfully, it will display End of Installation. Click on Exit and confirm to exit the installer.
To perform a silent installation requiring no user intervention:
Copy the response file template provided in the response directory where you unpacked the Patch Set tar file.
Edit the values for all fields labeled as "<Value Required>" according to the comments and examples in the template.
Start the installer from whichever of the directories described in Step 4 applies to your situation passing as the last argument the full path of the response file template you have edited locally with your own value of ORACLE_HOME and FROM_LOCATION:

% ./runInstaller -silent -responseFile <full_path_to_your_response_file>
If you have previously installed Oracle Label Security then add object files to library. This step is necessary because the installation of this patch set removes Oracle Label Security object files from RDBMS library.



Link in ols .o files using the following steps:
cd $ORACLE_HOME/lbac/lib
make -f lbac.mk xkzl
make -f lbac.mk ilbac
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk ioracle

Disabling system triggers.
Before performing the next step, you must first set _SYSTEM_TRIG_ENABLED = FALSE in the initialization parameter file. To do this add the following line to your init<sid>.ora file and restart the database (see Note 149948.1 in Metalink for more information on this issue).
_system_trig_enabled=false

Invoke SQL*Plus (sqlplus), connect as internal and run the following:
select * from duc$ where PACK='JIS$INTERCEPTOR$' ;
If no rows were returned go to the next step. If a row was returned delete it using the following:
delete from duc$ where PACK='JIS$INTERCEPTOR$' ;
commit;

Invoke SQL*Plus (sqlplus), connect as internal and run the following SQL scripts with event 10520 set. NOTE: This event is not intended for regular database operation and when turned on below by the 'ALTER SESSION' command will automatically be turned off by the subsequent 'CONNECT' command.
ALTER SESSION SET EVENTS '10520 TRACE NAME CONTEXT FOREVER, LEVEL 10';
?/rdbms/admin/catalog.sql
?/rdbms/admin/catproc.sql
?/rdbms/admin/catrep.sql (This only needs to be run if you are using symmetric/advanced replication. This is not necessary for sites using dblinks and read-only snapshots if symmetric/advanced replication is not installed)
CONNECT / AS SYSDBA;
update obj$ set status=5 where type#=29 and owner#!=0;
commit;


You can ignore this step if you have already executed it as part of a previous 8.1.7 patch set install.
If Java has previously been loaded into the database, invoke SQL*Plus (sqlplus), connect as internal and run the following SQL DDL command(* Note:If Java has not previously been loaded into the database, skip this step).:
SQL> create or replace java system
2 /
(Note that the / (slash) is important to ensure the execution of the command).
To ensure the correct installation of the XDK in the database run the following 2 scripts (Bug 2115227):
$ORACLE_HOME/oracore/admin/initxml.sql
$ORACLE_HOME/rdbms/admin/catxsu.sql * To determine whether Java has previously been loaded into the database:
invoke SQL*Plus (sqlplus), connect as internal and run the following:
SQL> select count(*) from all_objects where object_type like 'JAVA%';

Java is installed if you get a non zero result returned from the query.



You can ignore this step if you have already executed it as part of a previous 8.1.7 patch set install:
If Java has previously been loaded into the database, invoke SQL*Plus (sqlplus), connect as internal and run the following scripts which are located in $ORACLE_HOME/javavm/install ( Note: If Java has not previously been loaded into the database, you can skip this step):
load_jis.sql
jisja.sql
initjsp.sql
jspja.sql
Notes:
When running the $ORACLE_HOME/javavm/install/jisja.sql script the following error may be reported and can be ignored:
call jis_exit_java_session(0)
ERROR at line 1:
ORA-29515: exit called from Java code with status 0
Bug 1459233 was filed against this problem which is fixed in 9i.


If you deleted a row from duc$ in step 8 then reinsert it again. Invoke SQL*Plus (sqlplus), connect as internal and run the following SQL:
insert into duc$ (OWNER, PACK, PROC, FIELD1, OPERATION#, SEQ) values ('SYS', 'JIS$INTERCEPTOR$', 'USER_DROPPED', 0, 1, 1);
commit;


Enabling system triggers.
You must either remove _SYSTEM_TRIG_ENABLED from the initialization parameter file or explicitly set it to TRUE before attempting any other patch set post-install steps. Restart the database.

This step is optional - it will recompile all invalid PL/SQL packages now rather than when accessed for the first time - you can also use utlrcmp.sql to parallelize this. Invoke SQL*Plus (sqlplus), connect as internal and run the following SQL script:
?/rdbms/admin/utlrp.sql

Execute the following steps only if you have installed Oracle interMedia Text in the database you are attempting to modify:
If you have not previously unlocked the ctxsys account and supplied a password for that account, you need to do so. (If you have needed to use Oracle Text in any way prior to applying the patchset, you will have already performed this step, and you can skip this.) Do so by issuing the following statement:
ALTER USER ctxsys IDENTIFIED BY <passwd> ACCOUNT UNLOCK;
If you have already installed 8.1.7.2 or 8.1.7.3, go directly to step 7 below.
If you have already installed 8.1.7.1, go directly to step 5 below.
CONNECT ctxsys/<passwd>;
@?/ctx/admin/upgrade/u0801071.sql
CONNECT ctxsys/<passwd>;
@?/ctx/admin/upgrade/u0801072.sql
CONNECT / AS SYSDBA;
@?/ctx/admin/upgrade/s0801074.sql
CONNECT ctxsys/<passwd>
@?/ctx/admin/dr0pkh.sql
@?/ctx/admin/dr0plb.sql
@?/ctx/admin/dr0type.plb
@?/ctx/admin/dr0typec.plb

You can ignore this step if you have already executed it as part of a previous 8.1.7 patch set install:
The installation of this patch set fixes a potential security hole in the XSQL Servlet - see here for more detail. The patchset installation does not, however, modify any of the Oracle HTTP Server configuration files to reflect changes to the XSQL Servlet installation. If you have previously installed the Oracle HTTP Server, you will need to update one of the configuration files manually after the patchset installation is complete. If you do not do so, the XSQL Servlet may not work in the context of the Oracle HTTP Server after the patchset is installed. To update your Oracle HTTP Server configuration, perform the following steps:
1) Edit the file: $ORACLE_HOME/Apache/Jserv/conf/jserv.properties
2) Search for the string: "XSQLConfig.xml File location"
3) Modify the parameter wrapper.classpath on the line immediately following the above string to read: $ORACLE_HOME/oracore/admin
4) Save the file.

You can ignore this step if you have already executed it as part of a previous 8.1.7 patch set install:
The installation of this patch set fixes a potential security hole in the PL/SQL XML parser - see here for more detail. To load the new XML parser in to the database, run the following script as user SYS:
? /xdk/plsql/parser/bin/load.sql

If you are using the RMAN catalog then upgrade it as follows:
rman catalog <user/passwd@alias>;
upgrade catalog;
upgrade catalog;

The post install actions are now complete and the database is now ready for use.

To vskv: это несомненно. .dba же так и написал "exp версии 8.1.7.4 не работает с базой 8.1.7.2".
Про данную ошибку могу сказать следующее. У меня она была почти в подобной ситуации.У меня стоял Oracle 8.1.7.0.1, я установил патч через инсталлятор. Потом попытался сделать export. Вылезла такая же ошибка. Потом я просто вспомнил, что забыл пропатчить саму базу.
Я её пропатчил согласно интрукции и ошибка исчезла.
Подобные ситуации я встречал и у других - читал в других конфах. Причём проблема исчезла уже только при вполнении этих скриптов:
?/rdbms/admin/catalog.sql
?/rdbms/admin/catproc.sql
?/rdbms/admin/catrep.sql

?/rdbms/admin/utlrp.sql

Почему .dba так упорно не хочет их прогнать - я не понимаю. Если не поможет, ну значит не поможет, значит я не прав. Хотя с другой стороны это надо сделать обязательно