Oracle achète SUN

C'est une petite victoire pour moi puisque je l'avais prédit plusieurs fois en français, en anglais et même sur twitter à Paul, "partisan" du rachat par IBM...

Pour les informations officielles, regardez le site d'Oracle : http://www.oracle.com/sun . Bien sur il faut encore que tout le monde, actionnaires ou agences officielles tombent d'accord...

2 réflexions à propos de la commande MERGE

Il y a quelques jours, j'ai publié un post intitulé "Un Update Pas Si bête..." dans lequel j'illustrai la capacité qu'a Oracle à assurer la consistence des données et écriture. Si vous voulez en savoir plus, reportez-vous aux posts de Tom Kyte intitulés Write Consistency Part I, Part II et Part III.

Dans ce post, j'illustrerai que (1) les 2 sections d'un ordre MERGE ne sont pas exécutées de manière consistentes et (2) que vous pouvez utiliser un ordre MERGE pour supprimer des CHAINED ROWS.

Un schema exemple

Commençons par créer un schéma d'exemple constitué de 2 tables liées par une clé étrangère avec la contrainte ON DELETE CASCADE :

create table master_t(
     id number,
     text varchar2(50),
     constraint master_t_pk
                primary key(id)
     );

insert into master_t
   values (1,'Text 1');

insert into master_t
   values (2,'Text 2');

create table detail_t(
     master_id number,
     constraint detail_master_fk
                foreign key(master_id)
                references master_t(id)
                on delete cascade);

insert into detail_t
   values (1);

commit;

select rowid, id, text
from master_t;

ROWID      ID TEXT
------------------ --- ------
AAATLQAAEAAABY+AAA   1 Text 1
AAATLQAAEAAABY+AAB   2 Text 2

2 MERGE, 2 ORDER BY, 2 résultats

Les 2 exemples suivants illustrent que l'ordre dans lequel vous effectuez un MERGE a son importance et que, en quelque sorte, les différentes sections d'un ordre MERGE ne sont pas exécutées de manière consistente. Le second exemple présente comment vous pouvez remplacer, avec un MERGE une ligne par une nouvelle ligne:

• Exemple 1: Quand MERGE ne fonctionne pas
  

merge into master_t d
  using (select 'AAATLQAAEAAABY+AAA' rid from dual
         union all
         select 'AAATLQAAEAAABY+AAZ' from dual
         order by rid) s
on (d.rowid=s.rid)
when matched then
 update set d.id=9
when not matched then
 insert (id,text) values (1,'Text 1');

ORA-02292: integrity constraint (SCOTT.DETAIL_MASTER_FK) violated - child

• Exemple 2: MERGE pour changer le rowid d'une ligne;
  

merge into master_t d
  using (select 'AAATLQAAEAAABY+AAA' rid from dual
         union all
         select 'AAATLQAAEAAABY+AAZ' from dual
         order by rid desc) s
on (d.rowid=s.rid)
when matched then
 update set d.id=9
when not matched then
 insert (id,text) values (1,'Text 1');

2 rows merged.

select rowid, id, text
from master_t;

ROWID      ID TEXT
------------------ --- ------
AAATLQAAEAAABY+AAA   9 Text 1
AAATLQAAEAAABY+AAB   2 Text 2
AAATLQAAEAAABY+AAC   1 Text 1

commit;

delete from master_t where id=9;

commit;

select rowid, id, text
from master_t;

ROWID      ID TEXT
------------------ --- ------
AAATLQAAEAAABY+AAB   2 Text 2
AAATLQAAEAAABY+AAC   1 Text 1

select * from detail_t;

MASTER_ID
---------
       1

RAC et "profiles" des utilisateurs

Limiter les ressources à disposition d'une application est un bon moyen d'éviter les sur-accidents avec ou sans RAC! Plusieurs exemples viennent à l'esprit où un problème a dégénéré parce que l'application s'est comportée de manière inadéquate à la suite d'un incident. Dans le cas de RAC, votre base de données est censée survivre à plusieurs de ces incidents, alors...

Parmi ces exemples, un phénomène que vous avez malheureusement peut-être vécu vous-même : (1) les temps de réponse des requêtes se dégradent, (2) les serveurs d'applications allouent plus de connexions dans leurs pools, (3) de plus en plus de sessions sont actives sur les serveurs de base de données et (4) les temps de réponse des requêtes SQL sont de moins en moins bons.

Mettre en oeuvre "Resource Manager" et/ou les "Profiles" peut vous aider à limiter, à défaut de corriger, ces mauvais comportements d'une application ou d'un serveur d'applications. Mais ce n'est toutefois pas l'objet de ce post. L'objet, c'est plutôt: "Les limites des "profiles" sont-elles valables pour toute la base de données ou par instance?"

En effet, la documentation associée n'est pas très explicite; comme rien ne vaut de vérifier par soi-même, voici un extrait de mes tests:

create profile demo
 limit sessions_per_user 1;

create user demo
identified by demo
profile demo;

grant create session to demo;

-- Connect with session 1:
connect demo/demo

-- Connect with session 2 on the same node:
sqlplus /nolog
connect demo/demo

ERROR:
ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit

Warning: You are no longer connected to ORACLE.

-- Connect with session 2 on another node:
sqlplus /nolog
connect demo/demo

-- From a 3rd session, check the connections

col profile       format a10
col resource_name format a20
col limit         format a5

select profile, resource_name, limit
from dba_profiles
where profile='DEMO'
 and resource_name='SESSIONS_PER_USER';

PROFILE    RESOURCE_NAME        LIMIT
---------- -------------------- -----
DEMO       SESSIONS_PER_USER    1

select profile
from dba_users
where username='DEMO';

PROFILE
------------------------------
DEMO

-- Check the connected users:
select inst_id, count(*)
from gv$session
where username='DEMO'
group by inst_id;

INST_ID COUNT(*)
------- --------
    1        1
    2        1

-- Connect with session 3 on node 2:
sqlplus /nolog
connect demo/demo

ERROR:
ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit

Warning: You are no longer connected to ORACLE.

-- drop the user and profile;
drop user demo;
drop profile demo

Les limites sont donc valables par instance, même si vous ne pouvez pas definir des valeurs différentes pour chacune d'entre-elles. Avant de mettre en oeuvre cette fonctionnalité, regardez l'impact sur les requêtes parallèles.

Imprimer les paramètres d'une autre session?

Pour expliquer certains comportements, il est utile de connaitre les paramètres qui ont été modifiés dans une session. la commande oradebug dump modified_parameters 1 force la session à enregistrer les paramètres dans son fichier de trace;

Voici un exemple d'utilisation. D'abord, créez une première session dans laquelle, vous modifierez quelques paramètres; dans le réalité, il vous faudra déterminer la session ou le process qui vous intéresse:

select sys_context('userenv', 'sid') sid
 from dual;

SID
----
111

alter session set events '10053 trace name context forever, level 1';
alter session set global_name=false;
alter session set "_gby_hash_aggregation_enabled"=false;

pause

Connectez-vous avec une autre session, sous SYS; vérifiez le SPID du process correspondant et utilisez oradebug pour attacher le process et enregistrer les paramètres:

sqlplus / as sysdba

select s.sid, p.spid,  p.tracefile
 from v$session s, v$process p
where s.paddr=p.addr
  and s.sid=111;

      SID SPID
---------- ------------------------
TRACEFILE
----------------------------------------------------------------
      111 23682
/u01/app/oracle/diag/rdbms/black/BLACK/trace/BLACK_ora_23682.trc

oradebug setospid 23682;
Oracle pid: 18, Unix process pid: 23682, image: oracle@arkzoyd-laptop (TNS V1-V3)

oradebug dump modified_parameters 1;
Statement processed.

!tail -100 /u01/app/oracle/diag/rdbms/black/BLACK/trace/BLACK_ora_23682.trc

[...]
*** 2009-04-13 23:07:40.034
Processing Oradebug command 'dump modified_parameters 1'
DYNAMICALLY MODIFIED PARAMETERS:
 db_file_multiblock_read_count= 4
 global_names             = FALSE
 _gby_hash_aggregation_enabled= FALSE

*** 2009-04-13 23:07:40.035
Oradebug command 'dump modified_parameters 1' console output: <none>

Vous remarquez au passage que les events positionnés dans la session ne sont pas affichés.

Un UPDATE pas si bête...

Il y a des questions qu'on ne se pose jamais lorsqu'on utilise Oracle! Celle-ci en fait partie... "Comment influencer l'ordre dans lequel un update fait ses mises à jour?". D'où vient cette idée bizarre me direz-vous?

Soit une table T1 avec une colonne COL1 qui a une contrainte d'unicité.

create table t1(col1 number,
         constraint t1_col1_uk unique(col1));

begin
 for i in 1..10 loop
   insert into t1 values (i);
 end loop;
 commit;
end;
/

Imaginez que vous vouliez changer la valeur de 1 en 2, celle de 2 en 3, celle de 3 en 4, etc. Il suffit d'exécuter:

update t1 set col1=col1+1;

commit;

Bon ça marche! fin de l'histoire? Pas tout à fait: si vous capturer le SQL depuis Logminer et le rejouez, ça ne marche pas

alter system archive log current;

col name format a100 new_value archivelog
set lines 100

select name
 from v$archived_log
where sequence#=
     (select max(sequence#)
        from v$archived_log
       where thread#=(select thread#
                        from v$thread)
     );

NAME
-------------------------------
/archivelog/1_221_681179242.dbf

begin
 dbms_logmnr.add_logfile(
    logfilename => '&&archivelog',
    options => dbms_logmnr.new);
end;
/

exec dbms_logmnr.start_logmnr( options => -
    dbms_logmnr.dict_from_online_catalog);

select sql_redo
from v$logmnr_contents
where seg_owner=user
 and table_name='T1'
 and operation='UPDATE';

SQL_REDO
----------------------------------------------------------------------
update "SYS"."T1" set "COL1" = '2' where "COL1" = '1' and ROWID [...];
update "SYS"."T1" set "COL1" = '3' where "COL1" = '2' and ROWID [...];
update "SYS"."T1" set "COL1" = '4' where "COL1" = '3' and ROWID [...];
update "SYS"."T1" set "COL1" = '5' where "COL1" = '4' and ROWID [...];
update "SYS"."T1" set "COL1" = '6' where "COL1" = '5' and ROWID [...];
update "SYS"."T1" set "COL1" = '7' where "COL1" = '6' and ROWID [...];
update "SYS"."T1" set "COL1" = '8' where "COL1" = '7' and ROWID [...];
update "SYS"."T1" set "COL1" = '9' where "COL1" = '8' and ROWID [...];
update "SYS"."T1" set "COL1" = '10' where "COL1" = '9' and ROWID [...];
update "SYS"."T1" set "COL1" = '11' where "COL1" = '10' and ROWID [...];

Si vous annulez votre update et vous rejouez les ordres capturés par logminer, vous obtenez le résultat ci-dessous:

update t1 set col1=col1-1;
commit;

update "SYS"."T1" set "COL1" = '2'
where "COL1" = '1'
  and ROWID = 'AAATDpAABAAAVxpAAA';

update "SYS"."T1" [...]
*
ERROR at line 1:
ORA-00001: unique constraint (SYS.T1_COL1_UK) violated

Une erreur... Plutôt intéressant quand on sait que Streams utilise LogMiner pour la capture et qu'il retombe parfaitement sur ses pieds dans ce cas particulier, sans utiliser de contrainte DEFFERABLE.

Comment les autres s'en sortent? Intéressante question à laquelle je ne repondrai pas... Enfin, j'ai testé avec MySQL et pour vous en sortir, il faut ajouter une clause order by à votre update:

mysql>  select * from demo;
+----+
| id |
+----+
|  0 |
|  1 |
|  2 |
+----+
3 rows in set (0.00 sec)

mysql> update demo set id=id+1;
ERROR 1062 (23000): Duplicate entry '1' for key 1

mysql> update demo set id=id+1 order by id desc;
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

Reste qu'Oracle fait encore mieux, à l'image de la commande ci-dessous qui remplace en une seule passe 1 en 2 et 2 en 1:

update t1
  set col1=decode(col1,1,2,1)
where col1 in (1,2);

Oracle 10g Release 2 pour OS X - Intel x86_64

Oracle 10g Release 2 est disponible pour Mac OS X. Ce n'était plus le cas depuis 10.1.0.3 sur Power. Vous pouvez downloader la-dite version sur Oracle Technology Network.

Upgrade d'une base RAC sur un autre ORACLE_HOME

Changer d'ORACLE_HOME, lorsque vous faites un "upgrade" vers une version supérieure ou vers un Patch Set, offre plusieurs avantages; Cela permet:

• de conserver le ORACLE_HOME précédent sur le serveur et ainsi de faciliter le plan de retour arrière ^[1]
  
• de changer le chemin du ORACLE_HOME ^[2] et ainsi d'assurer la consistance avec les dénominations standard d'OFA,
• d'installer la nouvelle version ainsi que d'appliquer les patchs recommandés en général (cf 756671.1- Oracle Recommended Patches) ou pour des modules particuliers (e.g. 437838.1 - Streams Specific Patches), sans impacter la disponibilité de votre base de données ^[3].

Seulement, ce qui est une formalité dans le cas d'une single instance, nécessite plusieurs adaptations dans le cas de RAC... Voici ces modifications que vous devez réaliser lorsque vous changez une base de données RAC d'ORACLE_HOME sans l'aide des assistants^[4].

Remarque:
Gardez à l'esprit que les ressources ne doivent pas forcément être enregistrées dans le clusterware pour fonctionner; vous pouvez démarrer une instance avec SQL*Plus sans qu'il y ait de ressource associée dans l'OCR ou que la ressource ne soit pas paramétrée correctement (pour l'instant). Il en est de même pour ASM ou pour les listeners. Par contre, il est fondamental qu'en fonctionnement régulier les ressources du cluster existent et soient correctement paramétrées car elles supervisent les services Oracle. Vous pouvez donc temporairement démarrer une ressource alors qu'elle n'est pas encore configurée correctement dans le cluster et ainsi réduire l'indisponibilité de votre RAC lors d'un upgrade.

Changer le ORACLE_HOME des listeners

Si vous utilisez Oracle 11g, vous n'avez sans doute pas besoin de changer le ORACLE_HOME des listeners. En effet vous pourrez utiliser le ORACLE_HOME d'ASM et les nouvelles capacités de rolling upgrade du logiciel. Vous pouvez ainsi simplement mettre à jour chaque serveur séparément comme vous le faites pour le cluster.

Si vous voulez malgré tout, changer votre configuration, vous pouvez utiliser srvctl config listener
puis srvctl modify listener pour obtenir le résultat attendu. Cela arrivera, par exemple, si votre ORACLE_HOME précédent était une version 10g ou si vous utilisez le même ORACLE_HOME pour vos instances et vos listeners.

Dans le cas d'Oracle 10g, changer le ORACLE_HOME du listener est plus compliqué. La seule méthode supportée consiste à utiliser netca sur l'ancien ORACLE_HOME pour dé-enregistrer le listener et le réutiliser avec le nouveau ORACLE_HOME pour le ré-enregistrer. La bonne nouvelle, c'est que l'opération peut-être réalisée serveur par serveur. La mauvaise, c'est que la commande netca /silent /deinst /nodeinfo serverX ne fonctionne généralement pas. La méthode que j'utilise personnellement en 10g consiste donc à supprimer la ressource avec les outils du clusterware (même si ce n'est pas supporté) et utiliser netca seulement pour la reconfigurer:

cd $ORA_CRS_HOME/bin

export LSNR_RSC=`./crs_stat | grep "^NAME=" | grep ".lsnr$" |   \
        grep \`$ORA_CRS_HOME/bin/olsnodes -l\` | \
        cut -d = -f 2`

echo $LSNR_RSC

./crs_stop $LSNR_RSC
# ou si la commande précédente échoue:
# ./crs_stop $LSNR_RSC -f

./crs_unregister $LSNR_RSC

Une fois le listener supprimé, vous pouvez le recréer avec netca en mode silent:

cd $ORACLE_HOME/network/admin

mv listener.ora listener.ora.bak

which netca
ps -ef |grep [t]ns

export DISPLAY=:0

export nodename=`hostname | cut -d . -f 1`
echo $nodename

netca /silent  \
    /responsefile $ORACLE_HOME/network/install/netca_typ.rsp \
    /nodeinfo $nodename

srvctl status nodeapps -n $nodename

Si vous utilisez une configuration spéciale pour votre listener (e.g. adresses supplementaires, external procedure, enregistrement statique des instances, parametres...), vous pouvez simplement recopier le précédent fichier listener.ora.

Changer le ORACLE_HOME d'ASM

Changer le ORACLE_HOME d'ASM est très simple et s'effectue en quelques secondes. En 11g, vous pouvez utiliser le rolling upgrade de ASM comme discuté dans "11g ASM Rolling Upgrade et Oracle Database 10g". Sinon, vous devez arrêter toutes les instances ASM du RAC avant de changer la version d'une instance; suivez les étapes ci-dessous, si vous changez d'ORACLE_HOME:

• arrêter la ressource ASM,
  
• copier les fichiers init.ora, spfile, password file et tnsnames.ora,
  
• vérifier la configuration d'ASM stockée dans le cluster,
• Modifier le ORACLE_HOME de la ressource,
• redémarrer ASM
  

# Get Current Host/Instance/ORACLE_HOME

export nodename=`$ORA_CRS_HOME/bin/olsnodes -l`
echo $nodename

cd $ORA_CRS_HOME/bin

export instance_name=` srvctl config asm -n \`$ORA_CRS_HOME/bin/olsnodes -l\` \
                  |awk '{ print $1}'`

echo $instance_name

export old_oh=`srvctl config asm -n \`$ORA_CRS_HOME/bin/olsnodes -l\` \
                  |awk '{ print $2}'`

echo $old_oh

# Stop all the ASM instances
# Only for the 1st instance you restart!!!

for i in `$ORA_CRS_HOME/bin/olsnodes`;do
echo "Stopping ASM on $i..."
srvctl stop asm -n $i
done

# Copy all the files in the new ORACLE_HOME

echo $ORACLE_HOME
export new_oh=$ORACLE_HOME

cd $new_oh/dbs
cp -p $old_oh/dbs/init$instance_name.ora   $new_oh/dbs
cp -p $old_oh/dbs/spfile$instance_name.ora $new_oh/dbs
cp -p $old_oh/dbs/orapw$instance_name      $new_oh/dbs
cp -p $old_oh/network/admin/tnsnames.ora   $new_oh/network/admin
cp -p $old_oh/network/admin/sqlnet.ora     $new_oh/network/admin

# Check the stored ASM configuration
srvctl config asm -n $nodename

# Change the stored configuration
# Run this step as ROOT:
srvctl modify asm -n $nodename -i $instance_name -o $new_oh

# Start ASM
srvctl start asm -n $nodename
srvctl status asm -n $nodename

# If there is any problem check the alert.log
# and the crsd logs

Changer le ORACLE_HOME d'une base de données et de toutes ses instances

Les instances ne stockent pas leur ORACLE_HOME; seul la base de données y fait référence. Pour changer cette information dans le cluster, il suffit donc de modifier la variable à cet unique endroit; pour ce faire, utiliser srvctl comme ci-dessous:

# cluster database list:
srvctl config database

# Assuming ORCL is the registered resource
# for the database; display the configuration:
srvctl config database -d ORCL -a

# Change the ORACLE_HOME, if $new_oh is
# the new ORACLE_HOME. Run the command below
# as root:
srvctl modify database -d ORCL \
                    -o $new_oh

Changer le ORACLE_HOME des nodeapps

Vous ne devriez pas avoir à changer les ORACLE_HOME des nodeapps puisque ceux-ci référencent, en principe, le répertoire du clusterware. Toutefois, vous pouvez toujours utiliser srvctl modify nodeapps si celui-ci n'a pas été correctement paramétrés. Pour visualiser rapidement la valeur de ce paramètre, utilisez ocrdump -stdout -keyname comme ci-dessous:

export nodename=`$ORA_CRS_HOME/bin/olsnodes -l`
echo $nodename

ocrdump -stdout -keyname DATABASE.NODEAPPS.$nodename.ORACLE_HOME

Changer les ORACLE_HOME dans oratab

L'inconvénient de changer le ORACLE_HOME de votre base de données, vous l'aurez donc compris, tient dans le fait que celui-ci peut être utilisé dans de nombreux endroits; bien sur, il doit être référencé dans le fichier oratab mais il est possible que vous l'ayez stockés dans de nombreux autres endroits comme les fichiers de profile (/etc/profile, /etc/profile.d, .profile, .bashrc, .bash_profile,...), les scripts ou les outils de sauvegarde, de supervision, de nettoyage, la configuration de module comme DBD:Oracle ou encore certain rapports. Assurez-vous de faire l'inventaire de ces scripts avant de commencer votre mise à jour. Voici comment modifier cette variable dans le fichier oratab; on supposera que old_oh et new_oh sont respectivement les anciens et nouveaux ORACLE_HOME :

export old_str=`echo $old_oh|sed -e 's/\\//\\\\\\//g'`
export new_str=`echo $new_oh|sed -e 's/\\//\\\\\\//g'`
ed /etc/oratab <<EOF
%s/$old_str/$new_str/g
wq
EOF
unset old_str
unset new_str

Changer les ORACLE_HOME correspondants dans le Grid Control

Le ORACLE_HOME est généralement utilisé par les outils de supervision; c'est en particulier le cas pour le Grid Control. Une fois que vous avez changé une variable sur le serveur, vous devez réfléter ce changement dans la configuration du Grid Control. Pour ce faire, sélectionnez la cible modifiée et cliquez sur le bouton configure:

• Si vous avez modifié le ORACLE_HOME de votre base de données, connectez vous au Grid Control et sélectionnez la cible "cluster database" database correspondante; modifiez la propriété: "Oracle home path". Comme pour la resource dans le clusterware, cette information n'est pas stockée dans les instances.
• Si vous avez modifié le ORACLE_HOME de vos listener, sélectionnez les cibles "listener" correspondantes et modifiez les propriétés "listener.ora" et "Oracle Home"
• Si vous avez modifié le ORACLE_HOME de vos instances ASM, sélectionnez la cible "Automatic Storage Manager" correspondante et modifier la propriété: "Oracle home path".

Voilà ce que vous devez savoir faire un upgrade de RAC en utilisant un nouvel ORACLE_HOME. Racontez-moi vos exploits!

[1] Si vous voulez conserver le ORACLE_HOME pour faciliter un retour arrière et, malgré tout, le supprimer des disques, vous pouvez le détacher et le compresser. Vous pourrez toujours le rattacher ou le cloner comme décrit dans ce post: "Cloner un ORACLE_HOME d'une base de données RAC 10g".

[2] Il est recommandé de ne pas inclure le numéro de version majeur d'Oracle (e.g 10.2.0, 11.1.0), contrairement à ce qu'il est parfois écrit dans la documentation, dans le chemin du clusterware. N'incluez pas non plus ce numéro dans le chemin d'ASM s'il est installé en RAC à partir de 11g. Cette dénomination, sans numéro de version, permet d'effectuer une mise à jour "In-Place" comme recommandé dans ces 2 cas.

[3] Pour un Patch Set et dans le cas d'un RAC 2 noeuds, vous pouvez mettre à jour le logiciel sur un seul noeud en gardant ainsi l'autre noeud avec la précédente version; Pour cela, scinder l'inventory avec runInstaller -silent -UpdateNodeList ... -local. sur les 2 serveurs avec Oracle 10g; avec Oracle 11g, vous pouvez utiliser la possibilité qui est offerte de mettre à jour les logiciels séparemment sur des noeuds différents.

[4] Une alternative intéressante consiste utiliser DBUA en mode silent, au moins pour la base de données.

Intéressante discussion à propos des "Lost Blocks" sur Linux/Unix

Si vous utilisez les "Server-Generated Alerts" avec RAC; vous avez sans doute déjà rencontré le message d'alerte qui suivant:

Metrics "Global Cache Blocks Lost" is at XX

Fort de mon Packet Loss Myths, j'avais plutôt tendance à laisser courir! Mais après réflexion, et une bonne séance de tuning, il apparait que ce n'est pas forcément si anodin... Dans certain cas, si vous faites des full scan de table ou d'index, vos requêtes peuvent passer un temps significatif de leur exécution sur l'événement gc cr multi block. Ce que j'observe sur ce RAC (10.2.0.4 sur Linux x86_64), c'est que cet événement amène à la perte de blocs sur le réseau interconnect.

Après analyse, et la lecture assidue des 2 notes ci-dessous, il semble que le problème soit liés à la configuration de /net/core/rmem_default qui s'il est positionné à 256K est un peu court pour un multi_block_read_count=16 et des blocs de 8K:

• 563566.1 - gc lost blocks diagnostics
• 341788.1 - Recommendation for the Real Application Cluster Interconnect and Jumbo Frames

Je dois encore réaliser quelques tests pour reproduire ce comportement et m'assurer que j'ai bien compris ce qu'il se passe lorsque une requête attend sur l'événement gc cr multi block, et pourquoi les blocs sont perdus dans ce cas particulier lorsque les buffers sont trop petits. Enfin il semble que pour mon problème, augmenter les paramétres à 1Mo réduit mes waits et élimine les "Lost Blocks".

Et c'est là que commence la discussion! Si vous prêtez attention aux différentes notes/RDA qui définissent quelles devraient être les bonnes valeurs, surprise! Vérifiez par vous-même selon la source, la version, 32 ou 64 bits, vous trouvez une large éventail de valeurs entre 256K et 4M:

• Oracle® Database Quick Installation Guide 10g Release 2 (10.2) for Linux x86 6 Configuring Kernel Parameters
• Oracle® Database Installation Guide 10g Release 2 (10.2) for Linux x86 - 2.6 Configuring Kernel Parameters
• Oracle® Database Quick Installation Guide 11g Release 1 (11.1) for Linux x86 - 6 Configuring Kernel Parameters
• Oracle® Database Installation Guide - 11g Release 1 (11.1) for Linux - 2.8 Configuring Kernel Parameters
• 169706.1 - Oracle® Database on AIX®,HP-UX®,Linux®,Mac OS® X,Solaris®,Tru64 Unix® Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.1)

Il semblerait, si je lis entre les lignes qu'un consensus se dégage à 1M pour 10g et 4M pour 11g... Seulement voilà, si multi_block_read_count peut expliquer les 1M, pourquoi 4M avec 11g? Je sens qu'on ne me dit encore pas tout!