Dans ce billet, je vais vous montrer comment modifier le paramètre processes dans une base de données Oracle RAC.
Vous pouvez utiliser cette même méthode pour tout paramètre RAC qui nécessite un redémarrage des instances pour que le changement prenne effet.
Dans l'idéal, il suffirait de modifier les paramètres du système, puis d'arrêter et de démarrer chaque instance.
Mais cela n'a pas fonctionné comme prévu, car certains services n'étaient disponibles que dans un nœud et pas dans l'autre, de sorte que j'ai dû les déplacer et réessayer.
Je vous montrerai tous les détails dans ce billet.
Vous pouvez vérifier les limites actuelles du processus Oracle à l'aide de la requête suivante
SELECT INST_ID, RESOURCE_NAME, CURRENT_UTILIZATION, MAX_UTILIZATION, LIMIT_VALUE
FROM GV$RESOURCE_LIMIT
WHERE RESOURCE_NAME IN ( 'sessions', 'processes');
INST_ID RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION LIMIT_VALU
---------- ------------------------------ ------------------- --------------- ----------
1 processes 120 250 700
1 sessions 128 255 1074
3 processes 699 700 700
3 sessions 708 711 1074
Tout d'abord, je me connecte et je vérifie les valeurs actuelles.
set lines 200
column NAME format a40
column VALUE format a50
select INST_ID,NAME,VALUE from gv$parameter
where NAME in ('processes','sessions')
order by 2,1;
Une fois que j'ai les valeurs, je veux changer le paramètre des processus à 1500.
sqlplus / as sysdba
alter system set processes=1500 scope=spfile sid='*';
L'idéal serait donc d'arrêter et de redémarrer chacune des deux instances RAC.
[oracle@node1:XI002PRO1 ~]$ srvctl stop instance -d XI002PRO -i XI002PRO1
PRCD-1315 : failed to stop instances for database XI002PRO
PRCR-1014 : Failed to stop resource ora.xi002pro.db
PRCR-1065 : Failed to stop resource ora.xi002pro.db
CRS-2974: unable to act on resource 'ora.xi002pro.db' on server 'node1' because that would require stopping or relocating resource 'ora.xi002pro.xi002pro_bkup1.svc' but the appropriate force flag was not specified
J'ai donc vérifié tous les services de cette base de données.
[oracle@node1:XI002PRO1 ~]$ srvctl status service -d XI002PRO
Service XI002PROPLUGSVC is running on instance(s) XI002PRO1
Service xi002pro_bkup1 is running on instance(s) XI002PRO1
Service xi002pro_bkup2 is running on instance(s) XI002PRO3
Service XI002PROSVC is running on instance(s) XI002PRO1
Il se plaignait du service xi002pro_bkup1.
J'ai donc essayé de déplacer tous les services vers le nœud 3.
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service XI002PROPLUGSVC -oldinst XI002PRO1 -newinst XI002PRO3
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service xi002pro_bkup1 -oldinst XI002PRO1 -newinst XI002PRO3
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service XI002PROSVC -oldinst XI002PRO1 -newinst XI002PRO3
Puis il a réessayé
[oracle@node1:XI002PRO1 ~]$ srvctl stop instance -d XI002PRO -i XI002PRO1
[oracle@node1:XI002PRO1 ~]$ srvctl start instance -d XI002PRO -i XI002PRO1
Cette fois-ci, cela a fonctionné.
Je dois maintenant relocaliser les services sur le nœud 1.
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service XI002PROPLUGSVC -oldinst XI002PRO3 -newinst XI002PRO1
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service xi002pro_bkup1 -oldinst XI002PRO3 -newinst XI002PRO1
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service XI002PROSVC -oldinst XI002PRO3 -newinst XI002PRO1
Il reste un service qui était sur le nœud 3 et que je dois déplacer sur le nœud 1 pour démarrer et arrêter l'instance.
Mais je me suis heurté à un autre problème.
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service xi002pro_bkup2 -oldinst XI002PRO3 -newinst XI002PRO1
PRCR-1106 : Failed to relocate resource ora.xi002pro.xi002pro_bkup2.svc from node xfpcon01db03 to node node1
PRCR-1089 : Failed to relocate resource ora.xi002pro.xi002pro_bkup2.svc.
CRS-2717: Server 'node1' is not in any of the server pool(s) hosting resource 'ora.xi002pro.xi002pro_bkup2.svc'
Le problème est que ce service xi002pro_bkup2 n'est préféré que sur le nœud 3 et n'est même pas disponible sur le nœud 1 comme vous pouvez le voir avec ceci.
[oracle@node1:XI002PRO1 ~]$ srvctl config service -db XI002PRO -service xi002pro_bkup2
Service name: xi002pro_bkup2
Server pool:
Cardinality: 1
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Global: false
Commit Outcome: false
Failover type:
Failover method:
TAF failover retries:
TAF failover delay:
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Pluggable database name:
Maximum lag time: ANY
SQL Translation Profile:
Retention: 86400 seconds
Replay Initiation Time: 300 seconds
Session State Consistency:
GSM Flags: 0
Service is enabled
Preferred instances: XI002PRO3
Available instances:
J'ai donc ajouté ce service comme étant disponible au nœud 1 et préféré au nœud 3 et j'ai vérifié à nouveau.
[oracle@node1:XI002PRO1 ~]$ srvctl modify service -db XI002PRO -service xi002pro_bkup2 -modifyconfig -preferred XI002PRO3 -available XI002PRO1
[oracle@node1:XI002PRO1 ~]$ srvctl config service -db XI002PRO -service xi002pro_bkup2
Service name: xi002pro_bkup2
Server pool:
Cardinality: 1
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Global: false
Commit Outcome: false
Failover type:
Failover method:
TAF failover retries:
TAF failover delay:
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Pluggable database name:
Maximum lag time: ANY
SQL Translation Profile:
Retention: 86400 seconds
Replay Initiation Time: 300 seconds
Session State Consistency:
GSM Flags: 0
Service is enabled
Preferred instances: XI002PRO3
Available instances: XI002PRO1
Comme indiqué ci-dessus, le service est désormais privilégié sur le nœud 3 et disponible sur le nœud 1.
Je peux donc maintenant relocaliser le service sur le nœud 1.
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service xi002pro_bkup2 -oldinst XI002PRO3 -newinst XI002PRO1
Ensuite, je peux arrêter et démarrer l'instance dans le nœud 3.
[oracle@node1:XI002PRO1 ~]$ srvctl stop instance -d XI002PRO -i XI002PRO3
[oracle@node1:XI002PRO1 ~]$ srvctl start instance -d XI002PRO -i XI002PRO3
Je relocalise maintenant le service sur le nœud 3.
[oracle@node1:XI002PRO1 ~]$ srvctl relocate service -db XI002PRO -service xi002pro_bkup2 -oldinst XI002PRO1 -newinst XI002PRO3
Et je vérifie à nouveau la répartition des services sur chaque nœud pour voir s'ils sont de nouveau tels qu'ils étaient au début.
[oracle@node1:XI002PRO1 ~]$ srvctl status service -d XI002PRO
Service XI002PROPLUGSVC is running on instance(s) XI002PRO1
Service xi002pro_bkup1 is running on instance(s) XI002PRO1
Service xi002pro_bkup2 is running on instance(s) XI002PRO3
Service XI002PROSVC is running on instance(s) XI002PRO1
Je valide maintenant que la modification du paramètre "processus" a bien été appliquée.
sqlplus / as sysdba
set lines 200
column NAME format a40
column VALUE format a50
select INST_ID,NAME,VALUE from gv$parameter
where NAME in ('processes','sessions')
order by 2,1;
INST_ID NAME VALUE
---------- ---------------------------------------- --------------------------------------------------
1 processes 1500
3 processes 1500
1 sessions 2272
3 sessions 2272
Tout semble donc en ordre.
Bien sûr, si vous faites un peu de préparation avant d'effectuer l'arrêt et le démarrage de chaque instance, vous auriez pu éviter tout cela lors de l'intervention.
J'espère que cela vous a été utile.