De nombreux systèmes de stockage modernes, en particulier ceux basés sur mémoire flash ou SSD, ont vu augmenter la taille des secteurs (c’est-à-dire la taille minimum d’allocation possible) des périphériques de stockage. On est passé de leur valeur historique de 512 octets à la valeur plus efficace de 4096 octets (ou 4Ko).
On dispose maintenant, sous linux, de disques de secteur 4ko en mode émulation et mode natif.
Le mode émulation crée une taille de secteurs logique de 512 octets sur un secteur Physique de 4K pour permettre aux applications ne pouvant pas gérer des secteurs de 4K de continuer à fonctionner.
Pour vérifier si le mode taille de secteurs 512 octets émulé est disponible, c’est très simple :
Une fois connecté sur le serveur en tant que user root, lancez la commande fdisk -l
fdisk –l Disque /dev/sdba: 322.2 Go, 322163441664 octets 255 têtes, 63 secteurs/piste, 39167 cylindres Unités = cylindres de 16065 * 512 = 8225280 octets Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 65536 bytes Identifiant de disque : 0x00000000
Si la ligne Sector size indique une taille logique a 512 Bytes et une taille physique a 4096 Bytes, on dispose du mode 512 Bytes émulé.
D’une manière générale, le passage en taille de secteur de 4k est accepté par le noyau de base de données depuis la 11gR2.
Il n’en va pas de même pour la partie cluterware grid infrastructure, qui nous réserve quelques surprises, notamment dans sa version 12c.
Cela commence dès l’installation, lors de la mise en place de la base MGMTDB.
En effet, dans sa version 12.1.0.0, il est impossible de créer une base de données RAC sur un volume ASM avec des secteurs de 4K, la création du spfile étant impossible sur des disques avec des tailles secteurs de 4K. Pour cela, il faut être en version 12.1.0.2 minimum. Durant l’installation, il faut donc ignorer l’erreur de création de la base et, une fois l’installation terminée et le patch 12.1.0.2 passé, on recréera la base MGMTDB suivant les indications que j’ai déjà fourni dans un post précédent.
Pour la version 11.2.0.4, il faudra passer le dernier PSU pour bénéficier de la correction du bug.
Même problème en 11.2.0.2 ou en 11.2.0.3 avec ou sans le dernier PSU.
En effet, le bug n’a pas été corrigé dans ces versions de bases de données sous RAC. Pour pallier le problème, il faut soit créer un fichier spfile sur un file system standard, soit créer un montage acfs sur un disque ASM avec des tailles de secteurs à 512 octets.
Pour créer un disque ASM avec une taille de secteurs à 512 octets, il faut suivre la procédure suivante :
En tant que sysasm sur une des bases ASM du cluster, mettre à jour le spfile avec la commande suivante :
Alter system set "_disk_sector_size_override"= true;
Ce paramètre étant dynamique, il est pris en compte immédiatement.
Puis, créez le diskgroup voulu avec des tailles de secteurs à 512 octets avec la commande suivante :
CREATE DISKGROUP SPFILEPRDA_11200 EXTERNAL REDUNDANCY DISK 'ORCL:ORACLESPFILE' ATTRIBUTE 'SECTOR_SIZE'='512', 'compatible.asm' = '12.1.0.2.0', 'compatible.rdbms' = '12.1.0.2.0', 'compatible.advm' = '12.1.0.2.0';
Une fois le disque disponible, vous pouvez créer votre montage acfs pour y stocker les spfiles en version 11.2.0.2 et 11.2.0.3.
Attention, le fait d’avoir passé le paramètre « _disk_sector_size_override » à la valeur true ne permet plus d’utiliser asmca pour créer les nouveaux diskgroups. Ceux-ci doivent être créés manuellement. En effet asmca n’est pas capable de définir la taille du secteur à allouer au nouveau disque.
Par contre, l’ajout de disques à un diskgroup déjà existant peut toujours se faire par asmca.
Une autre solution, si on est en mode émulé 512 octets et que l’on utilise les packages asmlib pour définir les disques asm sur des partitions linux, c’est de passer le paramètre ORACLEASM_USE_LOGICAL_BLOCK_SIZE à true dans le fichier /etc/sysconfig/oracleasm.
Dans ce cas, les disques ASM seront créés avec des tailles de secteurs de 512 octets.
