Tips Oracle/Aix

# vmstat -v
Si pending disk I/O blocked with no pbuf s'incrémente : alors empilement dans la couche LVM
Si paging space I/O blocked with no psbuf s'incrémente ainsi que external pager line, alors, il faut voir la valeur j2_dynamicBufferPreallocation via ioo

# lvmo -a -v datavg
Si pervg_blocked_io_count s'incrémente, alors, utiliser ioo pour augmenter pv_min_pbuf à 2048, ou lvmo -v datavg -o pv_pbuf_count=2048 (là, on ne change que pour le vg)

Lors de la création des fs pour oracle : mettre un agblksize=512. Par défaut, on est à 4096, et on risque de faire des I/O inutiles. Les autres fs peuvent garder leur taille par défaut, par contre, celui qui contient les dbf, doit avoir son agblksize à db_block_size*db_file_multiblock_read_count. Ces parametres sont à voir avec les dbas.

Si le block size est à plus de 4096, oracle recommande 4096. Sinon 1024 ou 2048.

Pour connaitre le blocksize d'un fs : lsfs -q

Pour les I/O asynchrones :

iostat -A pour récupérer des stats

Si maxg s'approche de maxreqs, augmenter maxreqs.

Préconisation Oracle:

Il faut préferer les parametres Oracle suivants :

• filesystemio_options=setall
• disk_async_io=true

Séparer les redo et control files

Rapide résumé des direct io et autres concurrent IO (noté rapidement, à corriger) :

Le DIO existe depuis longtemps et est positionnable sur le JFS
Le CIO existe depuis peu et est positionnable sur le JFS2

Le CIO, permet de positionner un lock particulier sur l'inode du fichier sur lequel on travaille, et d'accéder le fichier en mode DIO de maniere implicite. En plus de l'accéder en direct IO, on peut accéder le fichier en multiple lectures/ecritures avec tous les locks gérés par oracle. Donc en clair, (encore une fois, de ce que j'ai compris) quand tu fais du CIO, tu fais implicitement du Direct IO, mais en plus en concurrent. Un des gros points forts du Direct IO est que tu t'affranchis des buffers JFS2 AIX (plus rapide dans certains cas, mais surtout, moins consommateur en ram),

Le gros point noir de tout ça, c'est qu'il peut etre genant, voire dangereux, de positionner autre chose que la base oracle en Concurrent IO ou Direct IO. Donc, il faut isoler les bases, si on veut monter les jfs2 avec le parametre CIO. C'est pour ça qu'en 9i c'était délicat, parce que c'était le seul moyen de taper les bases en Cio/Dio. Apparement avec oracle 10g, il n'est plus nécéssaire de positionner le JFS2 en Cio, il suffit de mettre en place le parametre filesystemio_options dans oracle à setall, et oracle se débrouille, et ouvre les fichiers qu'il veut acceder dans le mode qui lui convient le mieux.

En résumé, si on fait des gros accès séquentiels en lecture, avec peu d'écritures, il faut rester en asynchrone de base (via le jfs2), et si on fait des accès random, il vaut mieux bypasser le cache jfs2. Le direct IO seul est de toutes facons, déconseillé (parce que plus d'io asynchrones) si j'ai bien compris.

Par contre, pour fonctionner dans ce mode là, il faut avoir un outils de sauvegarde à chaud, ou bien sauvegarder les bases, avec oracle arreté. (en effet, si on passe une base (un table space ?) en read only pour la sauver, le fichier dbf est inaccessible.)