Vous utilsez une requête SQL dans laquelle vous passez des valeurs en paramètre dans la clause WHERE.
Dans SQL*PLUS vous voulez rappeler la même requête tout en remplaçant la valeur passée en paramètre par une autre valeur.
Utiliser la syntaxe:
c/ancien_valeur/nouvelle_valeur
Exemple:
Créer une table:
SQL> create table test (num number, libelle varchar2(5));
Table creee.
Insérer des données dans la table:
SQL> insert into test values (1, 'NY');
1 ligne creee.
SQL> insert into test values (2,'NY');
1 ligne creee.
SQL> insert into test values (3,'CA');
1 ligne creee.
SQL> insert into test values (4,'NY');
1 ligne creee.
SQL> insert into test values (5,'PA');
1 ligne creee.
SQL> commit;
Validation effectuee.
Rechercher les enrégistrements dont le libellé est PA.
SQL> select * from test where libelle='PA';
NUM LIBELLE
---------- -------------------------
5 PA
Rappeler la même requête sql en remplaçant PA par NY.
SQL> c/PA/NY
1* select * from test where libelle='NY'
SQL> /
NUM LIBELLE
---------- -------------------------
1 NY
2 NY
4 NY
SQL>
Hope it helps.
vendredi 9 novembre 2012
jeudi 8 novembre 2012
Clusterware PRC-1302: The "OCR", has an invalid IP address format
J'ai rencontré un problème avec un cluster 11.2.0.3 de 2 noeuds (zones solaris 11) sur lequel on essayait d'installer Oracle Database 11.2.0.3. Je souligne que le grid infrastructure n'a pas été installé par votre serviteur.
A un moment donné de l'installation on a rencontré l'erreur:
Un dump de l'OCR (avec la commande OCRDUMP) montre qu'il y a une incohérence dans l'OCR, d'où le message ci-dessus:
Vérification:
oifcfg getif
net7 192.168.101.0 rac1-lab cluster_interconnect
aggr2 10.53.228.0 rac1-lab public
net13 192.168.101.0 rac2-lab cluster_interconnect
aggr2 10.53.228.0 rac2-lab public
Une fois que les interfaces ont été nommées comme il se doit, c'est à dire le même nom pour les interfaces publiques sur les 2 noeuds, et le même nom pour les interfaces privées sur les 2 noeuds, corriger comme suit:
oifcfg setif -global aggr2/10.53.228.0:public
oifcfg delif -node rac1-lab aggr2/10.53.228.0
oifcfg delif -node rac2-lab aggr2/10.53.228.0
oifcfg setif -global net7/192.168.101.0:cluster_interconnect
oifcfg delif -node rac1-lab net7/192.168.101.0
oifcfg delif -node rac2-lab net13/192.168.101.0
Et le résultat final devra être:
oifcfg getif
aggr2 10.53.228.0 global public
net7 192.168.101.0 global cluster_interconnect
Hope it helps.
A un moment donné de l'installation on a rencontré l'erreur:
An internal error occurred within cluster verification framework
Une vérification de la configuration des interfaces réseaux avec la commande "oifcfg" montre que la configuration des interfaces dans le cluster n'est pas correct:
oifcfg iflist -p
Une autre vérification montre que les interfaces réseaux utilisées pour l'interconnect ne portent pas le même nom (net7 sur le noeud 1 et net13 sur le noeud 2). Même si ce n'est pas une contrainte d'avoir le même nom (pour ce qui est du réseau privé), c'est tout de même une recommandation d'oracle.
Après cette modification, l'on rencontre un autre message d'erreur:
Unable to obtain network interface list from oracle
Clusterware PRC-1302: The "OCR", has an invalid IP address format
Une vérification de la configuration des interfaces réseaux avec la commande "oifcfg" montre que la configuration des interfaces dans le cluster n'est pas correct:
oifcfg iflist -p
aggr2 10.53.228.0 PUBLIC
net7 192.168.101.0 PRIVATE
net7 169.254.0.0 PUBLIC
oifcfg getif
aggr2 10.53.228.0 global public
* 192.168.101.0 global cluster_interconnect
PRIF-29: Warning: wildcard in network parameters can cause mismatch among GPnP profile, OCR, and system
Pour corriger le problème, utiliser la commande "oifcfg":
oifcfg setif -global net7/192.168.101.0:cluster_interconnect
oifcfg delif -global */192.168.101.0
Une autre vérification montre que les interfaces réseaux utilisées pour l'interconnect ne portent pas le même nom (net7 sur le noeud 1 et net13 sur le noeud 2). Même si ce n'est pas une contrainte d'avoir le même nom (pour ce qui est du réseau privé), c'est tout de même une recommandation d'oracle.
Nous allons tout de même faire la modification pour avoir 2 noms différents le temps que les noms des interfaces soient homologués.
oifcfg setif -node rac1-lab net7/192.168.101.0:cluster_interconnect
oifcfg setif -node rac2-lab net13/192.168.101.0:cluster_interconnect
oifcfg delif -global net7/192.168.101.0
Après cette modification, l'on rencontre un autre message d'erreur:
oifcfg getif
net7 192.168.101.0 rac1-lab cluster_interconnect
net13 192.168.101.0 rac2-lab cluster_interconnect
aggr2 10.53.228.0 global public
Only in OCR: aggr2 10.53.228.0 global cluster_interconnect,public
PRIF-51: interface [aggr2] is set to both public and cluster_interconnect
PRIF-30: Network information in OCR and GPnP profile differs
net7 192.168.101.0 rac1-lab cluster_interconnect
net13 192.168.101.0 rac2-lab cluster_interconnect
aggr2 10.53.228.0 global public
Only in OCR: aggr2 10.53.228.0 global cluster_interconnect,public
PRIF-51: interface [aggr2] is set to both public and cluster_interconnect
PRIF-30: Network information in OCR and GPnP profile differs
Voici un extrait du dump de l'OCR:
[SYSTEM.css.interfaces.global.aggr2.10|d53|d228|d0.1]
ORATEXT : cluster_interconnect,public
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}
ORATEXT : cluster_interconnect,public
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_ALL_ACCESS, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}
Pour corriger:
oifcfg setif -node rac1-lab aggr2/10.53.228.0:public
oifcfg setif -node rac2-lab aggr2/10.53.228.0:public
oifcfg delif -global aggr2/10.53.228.0
Vérification:
oifcfg getif
net7 192.168.101.0 rac1-lab cluster_interconnect
aggr2 10.53.228.0 rac1-lab public
net13 192.168.101.0 rac2-lab cluster_interconnect
aggr2 10.53.228.0 rac2-lab public
Une fois que les interfaces ont été nommées comme il se doit, c'est à dire le même nom pour les interfaces publiques sur les 2 noeuds, et le même nom pour les interfaces privées sur les 2 noeuds, corriger comme suit:
oifcfg setif -global aggr2/10.53.228.0:public
oifcfg delif -node rac1-lab aggr2/10.53.228.0
oifcfg delif -node rac2-lab aggr2/10.53.228.0
oifcfg setif -global net7/192.168.101.0:cluster_interconnect
oifcfg delif -node rac1-lab net7/192.168.101.0
oifcfg delif -node rac2-lab net13/192.168.101.0
Et le résultat final devra être:
oifcfg getif
aggr2 10.53.228.0 global public
net7 192.168.101.0 global cluster_interconnect
Hope it helps.
jeudi 13 septembre 2012
SCAN: ORA-00119, ORA-00132 Incorrect Value for REMOTE_LISTENER
Vous voulez utiliser le SCAN (Single Client Access Naming) dans le paramètre REMOTE_LISTENER.
Mais vous rencontrez les messages d'erreur:
Cependant vous êtes sûr que le SCAN n'est pas en cause:
Le problème est tout simplement dû au fait que l'on utilise une chaine de connexion EZCONNECT.
Solution:
Dans le fichier sqlnet.ora local, ajouter EZCONNECT à la ligne NAMES.DIRECTORY_PATH=(TNSNAMES)
La ligne devient:
NAMES.DIRECTORY_PATH=(TNSNAMES,EZCONNECT).
Hope it helps.
Mais vous rencontrez les messages d'erreur:
SQL> alter system set
remote_listener='cluster-scan:1521' scope=both sid='*';
alter system set remote_listener='cluster-scan:1521' scope=both sid='*'
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00119: invalid specification for system parameter REMOTE_LISTENER
ORA-00132: syntax error or unresolved network name 'cluster-scan:1521'
alter system set remote_listener='cluster-scan:1521' scope=both sid='*'
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00119: invalid specification for system parameter REMOTE_LISTENER
ORA-00132: syntax error or unresolved network name 'cluster-scan:1521'
Cependant vous êtes sûr que le SCAN n'est pas en cause:
[oracle@svrhost1 ~]$ nslookup
cluster-scan
Server: 192.41.50.104
Address: 192.41.50.104#53
Name: cluster-scan.domaine.com
Server: 192.41.50.104
Address: 192.41.50.104#53
Name: cluster-scan.domaine.com
Address:
192.51.242.106
Name: cluster-scan.domaine.com
Address: 192.51.242.108
Name: cluster-scan.domaine.com
Address: 192.51.242.107
[oracle@srvhost1 ~]$
Name: cluster-scan.domaine.com
Address: 192.51.242.108
Name: cluster-scan.domaine.com
Address: 192.51.242.107
[oracle@srvhost1 ~]$
Le problème est tout simplement dû au fait que l'on utilise une chaine de connexion EZCONNECT.
Solution:
Dans le fichier sqlnet.ora local, ajouter EZCONNECT à la ligne NAMES.DIRECTORY_PATH=(TNSNAMES)
La ligne devient:
NAMES.DIRECTORY_PATH=(TNSNAMES,EZCONNECT).
Hope it helps.
mercredi 11 juillet 2012
Comment renommer un diskgroup avec ASM 11gR2
Le but de cet article est de présenter la commande "renamedg".
Le diskgroup à renommer ne contient ni ocr ni voting disk.
La commande "renamedg" située dans $GRID_HOME/bin permet de renommer un diskgroup dans ASM 11gR2 sans avoir à le supprimer et le recréer.
Pour voir la syntaxe:
$GRID_HOME/bin/renamedg -help
Exemple:
Nous avons un diskgroup appelé DATADG que nous souhaitons renommer en DATADG_NEW
Se connecter au serveur avec l'utilisateur ayant installé le grid infrastructure et positionner les paramètres d'environnement comme il se doit, puis:
Voir la liste des diskgroups actuels:
Démonter le diskgroup DATADG (le faire sur tous les noeuds en environnement RAC):
Revoir la liste des diskgroups:
Renommer le diskgroup:
Vérifier encore les diskgroups:
Monter le diskgroup renommé (le faire sur tous les noeuds en environnement RAC):
Vérifier les diskgroups:
Notes importantes:
1- Après avoir renommé le diskgroup, prendre le soin de renommer les fichiers qui étaient dans ce diskgroup, car le nom du diskgroup est inclus dans les noms des fichiers.
2- Lorsqu'on veut renommer un diskgroup qui contient l'ocr et les voting disks, la procédure est différente. Nous y reviendrons dans un autre article. Mais d'ores et déjà, il faut savoir qu'il faut créer un diskgroup temporaire dans lequel il faut déplacer l'ocr, le voting disk et le spfile file d'asm avant de renommer le diskgroup. Une fois la procédure terminée, retourner les fichiers dans le diskgroup renommé.
Hope it helps...
Le diskgroup à renommer ne contient ni ocr ni voting disk.
La commande "renamedg" située dans $GRID_HOME/bin permet de renommer un diskgroup dans ASM 11gR2 sans avoir à le supprimer et le recréer.
Pour voir la syntaxe:
$GRID_HOME/bin/renamedg -help
Exemple:
Nous avons un diskgroup appelé DATADG que nous souhaitons renommer en DATADG_NEW
Se connecter au serveur avec l'utilisateur ayant installé le grid infrastructure et positionner les paramètres d'environnement comme il se doit, puis:
Voir la liste des diskgroups actuels:
[oracle@svrhost1 ~]$ asmcmd lsdg
State
Type Rebal Sector
Block AU Total_MB
Free_MB Req_mir_free_MB Usable_file_MB Offline_disks
Voting_files Name
MOUNTED
EXTERN N 512
4096 1048576 1179801
107210 0 107210 0 N FRADG/
MOUNTED
EXTERN N 512
4096 1048576 409626
409521 0 409521 0 N
DATADG/
[oracle@svrhost1 ~]$
Démonter le diskgroup DATADG (le faire sur tous les noeuds en environnement RAC):
[oracle@svrhost1 ~]$ asmcmd umount DATADG
Revoir la liste des diskgroups:
[oracle@svrhost1 ~]$ asmcmd lsdg
State
Type Rebal Sector
Block AU Total_MB
Free_MB Req_mir_free_MB Usable_file_MB Offline_disks
Voting_files Name
MOUNTED
EXTERN N 512
4096 1048576 1179801
107210 0 107210 0 N
FRADG/
[oracle@svrhost1 ~]$
Renommer le diskgroup:
[oracle@svrhost1 ~]$ renamedg dgname=DATADG
newdgname=DATADG_NEW verbose=true
Parsing parameters..
Parameters in effect:
Old
DG name : DATADG
New DG name : DATADG_NEW
Phases :
Phase 1
Phase 2
Discovery str : (null)
Clean : TRUE
Raw only : TRUE
renamedg operation: dgname=DATADG newdgname=DATADG_NEW
verbose=true
Executing phase 1
Discovering the group
Performing discovery with string:
Identified disk
ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so:ORCL:DISK_AD3 with disk number:0
and timestamp (32969770 -442787840)
Checking for hearbeat...
Re-discovering the group
Performing discovery with string:
Identified disk
ASM:/opt/oracle/extapi/64/asm/orcl/1/libasm.so:ORCL:DISK_AD3 with disk number:0
and timestamp (32969770 -442787840)
Checking if the diskgroup is mounted or used by
CSS
Checking disk number:0
Generating configuration file..
Completed phase 1
Executing phase 2
Looking for ORCL:DISK_AD3
Modifying the header
Completed phase 2
Terminating kgfd context 0x7fa8e82920a0
[oracle@svrhost1 ~]$
Vérifier encore les diskgroups:
[oracle@svrhost1 ~]$ asmcmd lsdg
State
Type Rebal Sector
Block AU Total_MB
Free_MB Req_mir_free_MB Usable_file_MB Offline_disks
Voting_files Name
MOUNTED
EXTERN N 512
4096 1048576 1179801
107210 0 107210 0 N
FRADG/
[oracle@svrhost1 ~]$
Monter le diskgroup renommé (le faire sur tous les noeuds en environnement RAC):
[oracle@svrhost1 ~]$ asmcmd mount DATADG_NEW
Vérifier les diskgroups:
[oracle@svrhost1 ~]$ asmcmd lsdg
State
Type Rebal Sector
Block AU Total_MB
Free_MB Req_mir_free_MB Usable_file_MB Offline_disks
Voting_files Name
MOUNTED
EXTERN N 512
4096 1048576 409626
409521 0 409521 0
N DATADG_NEW/
MOUNTED
EXTERN N 512
4096 1048576 1179801
107210 0 107210 0 N
FRADG/
[oracle@svrhost1 ~]$
Notes importantes:
1- Après avoir renommé le diskgroup, prendre le soin de renommer les fichiers qui étaient dans ce diskgroup, car le nom du diskgroup est inclus dans les noms des fichiers.
2- Lorsqu'on veut renommer un diskgroup qui contient l'ocr et les voting disks, la procédure est différente. Nous y reviendrons dans un autre article. Mais d'ores et déjà, il faut savoir qu'il faut créer un diskgroup temporaire dans lequel il faut déplacer l'ocr, le voting disk et le spfile file d'asm avant de renommer le diskgroup. Une fois la procédure terminée, retourner les fichiers dans le diskgroup renommé.
Hope it helps...
jeudi 5 juillet 2012
Comment identifier le process id d'une session oracle
Vous avez une session oracle qui vous cause des troubles.
Vous avez identifié la session à problème et avez essayé de la tuer au niveau sql sans succès avec:
ALTER SYSTEM KILL SESSION 'sid , serial#';Vous souhaitez donc tuer la session à l'aide de son process ID au niveau de l'OS.
Mais comment identifier le process ID?
Utiliser la requête suivante:
col username format a20col osuser format a20col machine format a25col terminal format a15col program format a50SELECT s.sid, s.serial#, s.username, s.osuser, p.spid,
s.machine, p.terminal, s.program FROM v$session s, v$process
p WHERE s.paddr = p.addr;
Identifier le SPID de votre session à problème.
Puis au niveau du système d'exploitation:
Unix/Linux:
kill -9 <SPID>
Windows:
$ORACLE_HOME/bin/
orakill $ORACLE_SID <SPID>
Hope it helps...