Destination alternative pour les fichiers d'archive (archivelog files)

Pour les bases de données Oracle, on peut ajouter une destination alternative pour les fichiers d'archive (archivelog files) au cas où la destination primaire se remplisse ou devienne indisponible.

Par exemple, en supposant que la destination primaire est le groupe de disque "FRA1" sous Oracle Automatic Storage Management (ASM), il est possible d'ajouter comme destination alternative le groupe de disques (diskgroup), nommons-le "FRA2". Si jamais "FRA1" est plein, Oracle va automatiquement commencer à inscrire ses fichiers d'archive dans "FRA2". Lorsque "FRA1" redeviendra en état de recevoir des fichiers d'archive, Oracle va automatiquement recommencer à inscrire les fichiers dans "FRA1".

Ceci est un comportement normal pour les bases de données de la version 12c. Pour les bases de données de la version 11g, la destination alternative est aussi possible cependant si jamais la base de données bascule l’inscription des fichiers d'archive vers "FRA2", vous devrez manuellement réactiver la destination primaire.

Utilisation gratuite d'Oracle Cloud File System... la base, bien sûr!

Selon la documentation officielle, l'utilisation des fonctionnalités de base d'Oracle Cloud File System est gratuite pour tous les types de données, y compris les fichiers non-Oracle.

Oracle Cloud File System comprend Oracle ASM Cluster File System (Oracle ACFS) ainsi que le gestionnaire de volumes dynamiques Oracle ASM (Oracle ADVM).  L'utilisation des fonctionnalités de base est gratuite pour tous les types de données, y compris les fichiers non-Oracle cependant l'utilisation des fonctionnalités avancées d'Oracle ACFS nécessite la licence Cloud File System. Les fonctionnalités avancées sont composées des clichés (snapshot), de la réplication, du marquage (tagging), du realm-based security, le chiffrement et l'audit.

Autre particularité, Oracle prend en charge ACFS\/ADVM uniquement si le serveur exécute un produit d'Oracle, qui peut-être Oracle Linux ou Oracle Solaris.

Référence: Oracle® Database Licensing Information 12c Release 1

Special thanks to Ara Shakian for his article (http://lnkd.in/bpDzt4N)

Statut inconnu (UNKNOWN) de l'instance ASM sous RAC

Voici une situation vécue avec une instance ASM 10g (10.2.0.4) dans un environnement Oracle Real Application Cluster (RAC) 10gR2 sur la plateforme IBM AIX 64 bits.

Le statut de l'instance ASM est devenu "UNKNOWN" et celles des bases de données hébergées sur le même noeud sont OFFLINE. Que se passe-t-il ?

Afin de comprendre, je me suis dirigé vers les fichiers de trace sous l'ORACLE_HOME d'Oracle ASM situé à l'emplacement suivant puis vérifier le contenu du fichier "ora.noeud01.ASM1.asm.log" :

$ cd /opt/oracle/product/asm10g/log/noeud01/racg
$ vi ora.noeud01.ASM1.asm.log (writing error)

Le fichier de trace contenait l'erreur suivante :

RACG][1] [905406][1][ora.noeud01.ASM1.asm]: CLSR-0006: Error encountered when writing file /opt/oracle/product/crs10g/racg/tmp/ora.noeud01.ASM1.asm.ora

Je me suis alors déplacé vers le répertoire "/opt/oracle/product/crs10g/racg/tmp" pour vérifier les fichiers présents et leurs permissions.

$ cd /opt/oracle/product/crs10g/racg/tmp
$ ls -al

Voyant que tout semblait correct et que rien n'attirait mon attention, j'ai prit la décision de déplacer tous les fichiers de ce répertoire vers un autre répertoire dans le but de laisser Oracle les recréer au besoin :

# mkdir -p /tmp/backup
# mv * /tmp/backup

Suite au déplacement, j'ai redémarré le CRS puis revérifier graduellement le statut de chacune des composantes :

# crsctl stop crs
# crsctl start crs
# crsctl check crs
# crs_stat.sh

Toutes les composantes ont redémarrées correctement. Maintenant, je dois investiguer pour comprendre ce qu'il s'est réellement passé.

ORA-01078 au démarrage d'une instance Oracle 11g sous ASM

J'ai rencontré cette erreur lors d'un redémarrage de la base de données suite à des modifications de paramètres de bases de données qui sont stockés dans un SPFILE.

La base de données est de la version Oracle 11gR2 et elle est liée à un Grid Infrastructure qui utilise Oracle ASM et Oracle Restart.

Voici les étapes que j'ai suivi pour résoudre le problème :

--
oracle@romeo:/tmp> srvctl stop database -d F100
oracle@romeo:/tmp> srvctl start database -d F100
PRCR-1079 : Failed to start resource ora.f100.db
ORA-01078: failure in processing system parameters
CRS-2674: Start of 'ora.f100.db' on 'romeo' failed

--
-- Tentative de démarrage avec SQL*Plus
--
oracle@romeo:/tmp> sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Mer. Mai 5 12:07:49 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup nomount;
ORA-01078: failure in processing system parameters
ORA-00844: Parameter not taking MEMORY_TARGET into account
ORA-00851: SGA_MAX_SIZE 1577058304 cannot be set to more than MEMORY_TARGET 1358954496.

--
-- Tentative de correction de la valeur du paramètre en erreur
--
SQL> alter system set SGA_MAX_SIZE=100 scope=spfile;
alter system set SGA_MAX_SIZE=100 scope=spfile
*
ERROR at line 1:
ORA-01034: ORACLE not available
ID de processus : 0
ID de session : 0, Numéro de série : 0

--
-- Essai de création du pfile à l'image du spfile
--
SQL> create pfile='/tmp/pfileEC.ora' from spfile;
create pfile='/tmp/pfileEC.ora' from spfile
*
ERROR at line 1:
ORA-01565: error in identifying file '?/dbs/spfile@.ora'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

--
-- Afficher l'emplacement exact du SPFILE
--
SQL> ! cat $ORACLE_HOME/dbs/initF100.ora
SPFILE='+SYSDG01/F100/spfileF100.ora'

--
-- Création du pfile à l'image du spfile
--
SQL> create pfile='/tmp/pfileEC.ora' from spfile='+SYSDG01/F100/spfileF100.ora';

File created.

SQL> exit

--
-- Éditer le pfile pour enlever la ligne SGA_MAX_SIZE
--
oracle@romeo:/tmp> vi pfileEC.ora

--
-- Redémarrer la base de données avec le PFILE pour s'assurer
-- aucune autre erreur
--
oracle@romeo:/tmp> sqlplus / as sysdba


SQL*Plus: Release 11.2.0.1.0 Production on Mer. Mai 5 12:12:40 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.


Connected to an idle instance.

SQL> startup pfile='/tmp/pfileEC.ora'

ORACLE instance started.

Total System Global Area 1871208448 bytes
Fixed Size 2149152 bytes
Variable Size 1325405408 bytes
Database Buffers 536870912 bytes
Redo Buffers 6782976 bytes
Database mounted.
Database opened.

--
-- Création du spfile à l'image du pfile
--
SQL> Create spfile='+SYSDG01/F100/spfileF100.ora' from pfile='/tmp/pfileEC.ora';

File created.

--
-- Arrêt de la base de données
--
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit

--
-- Redémarrer la base de données à partir du Grid Infrastructure
--
oracle@romeo:/tmp> srvctl start database -d F100

Oracle Clusterware 11gR2

Oracle Clusterware est la composante majeure d’Oracle Grid Infrastructure et constitue la base d’Oracle Real Application Cluster (RAC). Oracle Clusterware permet de former un groupe de serveurs et de les faire fonctionner comme un seul système. Il permet de gérer l’ensemble des ressources, des processus et des applications du cluster tout en gérant et assurant la stabilité des nœuds.

Oracle Clusterware est composé principalement de deux éléments : le « voting disk » et l'OCR (Oracle Cluster Registry). Le « voting disk » est tout simplement un fichier qui contient et gère les informations de tous les nœuds liés au cluster et, l'OCR est un fichier qui gère le cluster et configuration RAC.

Depuis la version 11g Release 2, les fichiers de l’OCR et des voting disks peuvent maintenant être stockés dans ASM. D’ailleurs, cette façon de faire est conseillée par Oracle.
Dans les versions antérieures, la sauvegarde des « voting disks » en utilisant la commande « dd » était une tâche nécessaire suite à l’installation. Avec Oracle Clusterware 11gR2, la sauvegarde et la restauration d'un « voting disk » en utilisant la commande « dd » n'est plus supportée ni requise car ils sont sauvegardés automatiquement dans l’Oracle Cluster Registry (OCR) dès qu’un changement de configuration se produit. De plus, les données d’un « voting disks » sont automatiquement restaurées et appliquées sur un disque nouvellement ajouté.

Nouveautés intéressantes avec Clusterware 11gR2

Server Pool

• Division logique du cluster en pools de serveurs.
• Regroupement de serveurs ayant une charge similaire
• Gérer avec les outils crsctl (applications) et srvctl (Oracle)
• Définit par 3 principaux attributs (min, max, importance) ou une liste prédéfinie des nœuds
• Utilisation de règles (policies) pour contrôler l’utilisation du pool

Single Client Access Name (SCAN)

• Utilisé par les clients pour établir une connexion à n’importe quelle base de données du cluster
• Aucun changement nécessaire à la configuration de connexion d’un client advenant un changement au cluster
• Balancement de la charge parmi les instances desservit par un service
• Transparence lors d’un déplacement d’instance (failover)
• Permet aux clients d’utiliser une connexion de type « EZConnect » ou JDBC simple

Grid Plug and Play (GPnP)

• Simplifie l’ajout, le remplacement, et la suppression d’un noeud du cluster
• Permettre au cluster de gérer ses propres adresses IP virtuelles (Grid Naming Service)

Oracle Grid Infrastructure 11gR2

À partir d’Oracle 11g Release 2, Oracle Clusterware combiné à Oracle Automatic Storage Management (ASM) est devenu Oracle Grid Infrastructure.

Oracle Grid Infrastructure peut être déployé autant pour un environnement à multiples instances que simple instance (stand alone).

Pour les bases de données à simple instance, Oracle Grid Infrastructure permet de mettre en place une infrastructure légère de haute disponibilité. Cette option inclut deux composantes : Oracle Restart et Oracle ASM.

Pour les bases de données à multiple instance (RAC), Oracle Grid Infrastructure permet de mettre en place une réelle infrastructure de haute disponibilité regroupant plusieurs serveurs. Cette option inclut deux composantes : Oracle Clusterware et Oracle ASM.

Tablespace de type "bigfile"

Depuis Oracle 10g, il existe deux types de tablespace qui peuvent cohabiter dans une même base de données:

• bigfile
• smallfile

Un tablespace « smallfile » correspond au tablespace traditionnel, celui dont nous sommes habitués d’utiliser. Ce dernier peut contenir un maximum de 1022 fichiers de données.

Un tablespace « bigfile » peut contenir un seul fichier de données (datafile ou tempfile) qui peut être de taille imposante. Dépendamment de la taille du bloc Oracle, le fichier de données d’un tablespace « bigfile » peut atteindre la taille de 128 téraoctets.

Les tablespaces « Bigfile » sont seulement supportés avec la gestion locale des tablespaces (locally managed) et avec ASSM (automatic segment-space management). Ces options n’ont pas à être précisées car ce sont les défauts lors de la création d’un tablespace de type « bigfile » :

CREATE BIGFILE TABLESPACE TS DATAFILE '/u01/oradata/ts01.dbf' SIZE 2T;

Lorsqu’on augmente la taille d’un fichier, il n’est pas nécessaire d’utiliser l’option « datafile », l’utilisation du nom du tablespace pour altérer la taille du fichier de données est suffisant car le tablespace « bigfile » contient seulement un fichier de données.

Avec les commandes « CREATE DATABASE » ou « ALTER DATABASE », le type de tablespace par défaut peut être changé pour « BIGFILE ».

Le tablespace Undo géré localement et le tablespace temporaire peuvent être des « bigfile », même si leurs segments sont gérés manuellement.

Les tablespaces SYSTEM et SYSAUX ne peuvent pas être créés en bigfile.

Avec les tablespaces « bigfile », il est conseillé d’utiliser ASM (automatic storage management), ou tous autres gestionnaires de volume logique qui supporte l’extension dynamique, le striping et RAID.

Avec les tablespaces « smallfile », l’administrateur de bases de données avait la latitude d’augmenter un fichier de base de données ou d’ajouter un nouveau fichier de données pour accommoder l’évolution des données des applications. Tandis qu’un tablespace « bigfile », qui ne peut pas contenir plusieurs fichiers de données, l’administrateur de base de données doit s’assurer et prévoir suffisamment d’espace pour répondre à la capacité future.

L’utilisation des tablespaces de type « bigfile » n’a rien de négatif cependant, gardez en tête que le temps de recouvrement d’un fichier de données de plusieurs téraoctets risque d’être très long.