Dans les annexes « Oracle Flexible Architecture de guides d’Installation d’Oracle » comme celui-ci, Oracle propose un chemin d’installation pour le clusterware qui n’est pas compatible avec le reste de la documentation et le bon sens. Explications!
Le clusterware est mis à jour d’une version à l’autre « In Place », c’est à dire sans changer d’ORACLE_HOME. Si vous voulez changer d’ORACLE_HOME pour le clusterware, c’est possible; il vous faut l’arrêter et donc avec lui toutes les instances de bases de données RAC ou ASM du cluster. C’est donc très contraignant ! En général, vous vous choisirez la solution par défaut du « rolling upgrade » et vous retrouverez donc avec le même ORACLE_HOME après mise à jour du clusterware. Evidemment, si le numéro de version est dans le ORACLE_HOME, comme suggéré par OFA, il restera le même après la mise à jour et vous vous retrouverez avec un clusterware 11.1 dans un répertoire qui inclut 10.2.
Alors quel ORACLE_HOME pour le clusterware? La documentation n’est pas explicite sur le sujet ou au moins je n’ai jamais rien trouvé. Il y a quelques exemple comme que vous pouvez en extraire :
/crsdans Oracle® Database 2 Day + Real Application Clusters Guide/u01/app/crsdans Oracle® Clusterware Installation Guide for Linux
La deuxième solution est sans doute plus flexible puisqu’elle permet d’avoir un volume séparé pour tous les logiciels Oracle et de toutefois partager le même volume pour tous les logiciels; c’est d’ailleurs celle de mon post Oracle Silent Mode, Part 7: Installing an 11.1 RAC Database. Est-elle la plus logique ? Sans doute pas, mais toujours plus logique que de mettre le numéro de version dans le chemin du clusterware. Alors, s’il vous plait, arrêtez ça !
3 réflexions sur “A propos d'Oracle Flexible Architecture (OFA) et du Clusterware”
Hum si j’en crois la doc, le besoin de dissocier les comptes n’est valable que pour :
to give separate clusterware and database administrative privileges to those groups in a new Oracle Clusterware and Oracle Database installation.
Ca ne semble pas être ni un impératif ni une recommandation mais juste une possibilité.
Enfin, c’est ce que j’en ai compris 🙂
—
2.5.5 Creating the Oracle Clusterware User
You must create a software owner for Oracle Clusterware in the following circumstances:
*
If an Oracle software owner user does not exist; for example, if this is the first installation of Oracle software on the system
*
If an Oracle software owner user exists, but you want to use a different operating system user, such as crs, with different group membership, to give separate clusterware and database administrative privileges to those groups in a new Oracle Clusterware and Oracle Database installation.
In Oracle documentation, a user created to own only Oracle Clusterware software installations is called the crs user. A user created to own either all Oracle installations, or only Oracle database installations, is called the oracle user.
Note:
If you intend to use multiple Oracle software owners for different Oracle Database homes, then Oracle recommends that you create a separate Oracle software owner for Oracle Clusterware, and install Oracle Clusterware using the Oracle Clusterware software owner.
If you want to create separate Oracle software owners (oracle, crs, asm) to create separate users and separate operating system privileges groups for different Oracle software installations, then note that each of these users must have the oraInventory (or oinstall) group as their primary group, and each user must share the same oraInventory, to prevent corruption of the Central Inventory. Refer to « Creating Custom Configuration Groups and Users for Job Roles ».
Tu installes donc le clusterware dans l’utilisateur « oracle »… En 11g, la documentation suggère de créer des utilisateurs séparés pour clusterware et asm.
Moi j’aime bien
/u01/app/oracle/product/crs
…
/u01/app/oracle/product/10.2.0/db_1
/u01/app/oracle/product/11.1.0/db_1
Les commentaires sont fermés.