Rechercher sur arkzoyd.com

25 février 2008

RMAN DUPLICATE à partir d'un BEGIN/END BACKUP

Oui, La question est bien : "Comment utiliser la commande RMAN DUPLICATE à partir de fichiers de données sauvegardés avec BEGIN/END BACKUP ?" ou en tout cas c'est une des 2 questions auxquelles répond de ce post. Mais pourquoi donc ?

J'ai eu l'occasion, ces dernières semaines de travailler sur une manière de cloner un Disk Group ASM et le monter, en le renommant sur le même serveur (ou cluster, si vous préférez). D'ailleurs, un autre post devrait bientôt être publié en anglais sur le blog de Pythian à ce sujet. Il sous-entend que vous savez "cloner" une base de données Oracle avec BEGIN/END BACKUP, ce que sans doute 80% des DBA Oracle, moi le premier, ne font pas très régulièrement. Pourtant, si vous utilisez des baies de stockage ou un Volume Manager évolué, il existe encore des choses que RMAN, ASM, Active Duplicate ou Active Standby ne peuvent pas [encore] offrir.

Dupliquer de base de données avec BEGIN/END BACKUP permet de tirer parti de ces technologies et de "cloner" un environnement de plusieurs Tera-Octets en quelques minutes. Alors, vous trouverez ci-après 2 exemples qui illustrent les opérations à réaliser au niveau d'Oracle, avant, pendant et après la création d'un tel clone avec des logiciels de stockage. Pour cela, 2 approches distinctes sont mises en œuvre :
  • La recréation manuelle de la base de données et de son fichier de contrôle à partir de la commande "alter database backup controlfile to trace"
  • L'utilisation de la commande RMAN DUPLICATE
Les étapes de constitutions de votre base de données clone

Les 2 méthodes commencent par le même type d'opérations, à savoir la copie de vos fichiers en mode BEGIN/END backup. Certaines étapes, notamment celle de contrôle pourraient sans doute être éliminées mais au moins de cette manière vous pouvez vous assurer que tout est en ordre. Il s'agit de passer à travers ce qui suit :
  • Noter les numéros de séquences des redo logs courant
  • Passer la base de données en mode BEGIN BACKUP
  • Copier l'ensemble des datafiles ; utilisez la méthode de votre choix comme les Flexclones de Netapp, ou si vous utilisez une méthode de type BV ou BCV, arrêtez la synchro des miroirs.
  • Terminer le mode BACKUP de votre base de données
  • Générer une sauvegarde du fichier de contrôle sous forme de trace si vous voulez recréez le fichier manuellement (méthode 1) ou sous forme de vrai sauvegarde ou copie pour utiliser la commande DUPLICATE (méthode 2).
  • Noter les numéros de séquences des redo logs courant et les archiver
La méthode 1 "sans RMAN DUPLICATE" présente plusieurs inconvénients qui sont que : (a) Elle est plus complexe à transformer en script puisqu'il faut "parser" le fichier de trace et (b) le bug 5951527, vous empêchera de la mettre en œuvre sur le serveur sur lequel réside votre base de données d'origine (C'est du moins le cas avec les logiciels utilises pour cette démonstration, i.e. 10.2.0.4 pour Linux x86 32 bits). Elle consiste dans ce qui suit :
  • Mettre à disposition, par exemple sur un nouveau point de montage, les fichiers de données et les archivelogs
  • Créer un spfile et démarrer une nouvelle instance
  • Recréer un nouveau fichier de contrôle qui pointe sur les clones des fichiers de données et fichiers journaux.
  • Ajouter les autres threads de redo logs si vous avez plusieurs threads actifs (Le plus souvent avec RAC)
  • Enregistrer les fichiers archivelogs dans votre nouveau fichier de contrôle
  • Faire le recover de la base de données avec les archive logs
  • Ouvrir la base de données en mode RESETLOGS
  • Ajouter les fichiers temporaires
  • Ouvrir l'accès à votre clone de base de données.
La méthode 2, vous permet quant à elle d'utiliser la commande RMAN DUPLICATE, comme vous le feriez avec une sauvegarde classique. La seule différence par rapport à une commande RMAN DUPLICATE effectuée à partir d'une sauvegarde RMAN est qu'il vous faudra enregistrer les copies des fichiers effectuées pendant le BEGIN/END backup dans le fichier de contrôle de la base de données originale. Ces fichiers doivent être accessible, depuis l'environnement original et au moins le temps de l'enregistrement, dans l'arborescence dans laquelle vous allez recréer la base de données. Le fait que ces fichiers soient à l'endroit de la restauration permet à la commande DUPLICATE d'éviter cette étape ; la constitution du clone ne dure plus, alors, que quelques minutes. La contrainte de cette méthode réside donc dans les nécessités (a) de pouvoir accéder à l'arborescence du clone depuis la base de données primaire au moins le temps de la première étape et (b) d'accèder à la base primaire via le réseau à un utilisateur SYSDBA. Cette méthode 2 consiste donc dans ce qui suit :
  • Enregistrer les copies des fichiers de données dans le fichier de contrôle de la base de données originale depuis l'emplacement dans lequel ils seront "restaurés".
  • Mettre à disposition, dans la même arborescence que l'originale, les fichiers archivelog et la sauvegarde ou copie du fichier de controle
  • Créer un spfile et démarrer une nouvelle instance
  • Lancer la commande DUPLICATE avec les options adéquates
  • Ouvrir l'accès à votre clone de base de données.
Maintenant que vous savez quoi faire, nous allons l'illustrer avec 1 exemple concret pour chacune des méthodes. Pour ce qui suit, nous allons supposer que la base d'origine s'appelle BLACK et que nous allons la cloner avec une instance nommée WHITE. Dans le cas de la méthode 2, la base de données sera renommée WHITE ; Pour la méthode 1, libre à vous d'utiliser DBNEWID une fois le clone constitue. Les tests ont été réalisés avec Oracle 10.2.0.4 sur Linux 32 bits. Ils devraient fonctionner sans trop de modifications sur 11g...

Effectuer la copie de votre base de données
  • Noter les numéros de séquences des redo logs courant
SQL> select THREAD#,  SEQUENCE#, GROUP#
from v$log

where STATUS='CURRENT';


THREAD# SEQUENCE# GROUP#
------- ---------- ----------
1 34 3
  • Passer la base de données en mode BEGIN BACKUP... Il faut évidemment que votre base de données soit en mode ARCHIVELOG :
SQL> alter database begin backup;
  • Copier l'ensemble des datafiles ; utilisez la méthode de votre choix comme les Flexclones de Netapp, ou si vous utilisez une méthode de type BV ou BCV, arrêtez la synchro des mirroirs.

  • Terminer le mode BACKUP de votre base de données
SQL> alter database end backup;
  • Générer une sauvegarde du controlfile
Dans le cas de la méthode 1, vous utiliserez la commande qui suit :
SQL> alter database
backup controlfile to trace
as '/tmp/control.trc';
Dans le cas de la méthode 1, vous prefererez sans doute RMAN sur la base originale. Soyez attentif que le répertoire dans lequel vous effectuer votre sauvegarde doit exister sur les 2 serveurs ; vous choisirez la méthode qui vous contient pour copier le fichier du serveur d'origine au serveur de la base clone :
$ rman target /

RMAN> backup current controlfile
format '/tmp/controlfile-bkp';
  • Noter les numéros de séquences des redo logs courant et les archiver
SQL> select THREAD#,  SEQUENCE#, GROUP#
from v$log
where STATUS='CURRENT';

THREAD# SEQUENCE# GROUP#
------- ---------- ----------
1 35 3

SQL> alter system archive log current;

System altered.

Constituer la base clone avec la méthode 1 :
  • Mettre à disposition, par exemple sur un nouveau point de montage, les fichiers de données clonées. Vous pouvez envoyez les fichiers d'archive logs entre les séquences notées au début et à la fin de l'opération de clone et accessible à partir du serveur sur lequel vous voulez monter le clone de votre base de données. Si vous avez cloné les fichiers de contrôle, supprimez les ou renommez-les.

  • Créer un spfile et démarrer une nouvelle instance. Le plus simple peut-être de partir du spfile de votre base de données d'origine.
SQL> create pfile='/tmp/initWHITE.ora' from spfile;

[o Deplacez le fichier dans le $ORACLE_HOME/dbs sous Unix/Linux
ou %ORACLE_HOME%/database sous Windows sur le logiciel cible
o Modifiez le contenu du fichier en en particulier l'ensemble
des chemin pour convenir à votre clone ET ajouter le paramètre
db_unique_name pour qu'il corresponde, par exmple au nom de votre
instance si vous voulez monter la base de données clone sur le meme
serveur ue l'originale
o Créez ce qu'il faut pour votre nouvelle instance Password
file (avec orapwd), service sous Windows (avec oradim),
/etc/oratab sous Linux...]

$ cat /u01/app/oracle/product/10.2.0/db_1/dbs/initWHITE.ora

*.audit_file_dest='/u01/app/oracle/admin/WHITE/adump'
*.background_dump_dest='/u01/app/oracle/admin/WHITE/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/u01/app/oracle/oradata/WHITE/control01.ctl','/u01/app/oracle/oradata/WHITE/control02.ctl','/u01/app/oracle/oradata/WHITE/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/WHITE/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='BLACK'
*.db_unique_name='WHITE'

*.db_recovery_file_dest_size=2147483648
*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
*.job_queue_processes=10
*.nls_length_semantics='BYTE'
*.open_cursors=300
*.pga_aggregate_target=25165824
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.resource_manager_plan=''
*.sga_target=167772160
*.undo_management='AUTO'
*.undo_retention=900
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/WHITE/udump'

$ mkdir -p /u01/app/oracle/admin/WHITE/adump
$ mkdir -p /u01/app/oracle/admin/WHITE/bdump
$ mkdir -p /u01/app/oracle/admin/WHITE/cdump
$ mkdir -p /u01/app/oracle/admin/WHITE/udump

$ . oraenv
ORACLE_SID = [WHITE] ? WHITE
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Sun Feb 24 22:26:42 2008

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Connected to an idle instance.

SQL> startup nomount;

ORACLE instance started.

Total System Global Area 167772160 bytes
Fixed Size 1266392 bytes
Variable Size 62917928 bytes
Database Buffers 100663296 bytes
Redo Buffers 2924544 bytes
  • Recréer un nouveau fichier de contrôle qui pointe sur les clones des fichiers de données et fichiers journaux. L'opération de création du control file est dans la section "Set #2. RESETLOGS case" du fichier de "backup to trace" du controlfile original. Modifiez les chemin à vos fichiers mais pas le nom de la base de données.
SQL> CREATE CONTROLFILE DATABASE BLACK RESETLOGS  ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/app/oracle/oradata/WHITE/redo01.log' SIZE 50M,
GROUP 2 '/u01/app/oracle/oradata/WHITE/redo02.log' SIZE 50M,
GROUP 3 '/u01/app/oracle/oradata/WHITE/redo03.log' SIZE 50M
-- STANDBY LOGFILE
DATAFILE '/u01/app/oracle/oradata/WHITE/system01.dbf',
'/u01/app/oracle/oradata/WHITE/undotbs01.dbf',
'/u01/app/oracle/oradata/WHITE/sysaux01.dbf',
'/u01/app/oracle/oradata/WHITE/users01.dbf'
CHARACTER SET WE8ISO8859P15;
Si vous voulez utiliser cette méthode sur le serveur original, le bug #5951527 pourrait vous empêcher de créer fichier de contrôle. Pour le contourner, (a) Arrêtez la base originale, (b) Créez le controlfile du clone, (c) Arrêtez le clone, (d) Redémarrez l'originale, (e) Redemarrez le clone. Le paramètre db_unique_name positionne sur le clone fera le reste.
  • Ajouter les autres threads de redo logs si vous avez plusieurs threads actifs (Le plus souvent avec RAC). Les commandes correspondantes sont également dans le fichier de "backup to trace" du controlfile original. Si vous avez plusieurs thread, vous devrez les créer avant d'ouvrir votre base de données avec le RESETLOGS.

  • Enregistrez les fichiers archivelogs dans votre nouveau fichier de contrôle. On supposera que vous avez poussé ces fichiers archivelog dans la même arborescence que l'originale. Le plus simple pour enregistrer ces fichiers dans le nouveau fichier de controle est d'utliser la commande RMAN CATALOG comme ci-dessous :
$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Sun Feb 24 23:27:24 2008

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

connected to target database: BLACK (DBID=330918259, not open)

RMAN> catalog start with
'/u01/app/oracle/flash_recovery_area/BLACK/archivelog';


using target database control file instead of recovery catalog
searching for all files that match the pattern /u01/app/oracle/flash_recovery_area/BLACK/archivelog

List of Files Unknown to the Database
=====================================
File Name: /u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_24/o1_mf_1_34_3w4cw6xw_.arc
File Name: /u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_24/o1_mf_1_35_3w4jwqq9_.arc

Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_24/o1_mf_1_34_3w4cw6xw_.arc
File Name: /u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_24/o1_mf_1_35_3w4jwqq9_.arc

  • Faire le recover de la base de données avec les archive logs. La encore RMAN est sans doute plus simple que sqlplus :
RMAN> recover database until sequence 35;

Starting recover at 24-FEB-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK

starting media recovery

archive log thread 1 sequence 34 is already on disk as file /u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_24/o1_mf_1_34_3w4cw6xw_.arc
archive log filename=/u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_24/o1_mf_1_34_3w4cw6xw_.arc thread=1 sequence=34
media recovery complete, elapsed time: 00:00:03
Finished recover at 24-FEB-08
  • Ouvrez la base de données en mode RESETLOGS
RMAN> alter database open resetlogs;

database opened

RMAN> exit
  • Ajouter les fichiers temporaires une fois la base ouverte et toujour en vous appuyant sur le fichier de "backup to trace" du controlfile original :
$ sqlplus / as sysdba

SQL> ALTER TABLESPACE TEMP
ADD TEMPFILE '/u01/app/oracle/oradata/WHITE/temp01.dbf'
SIZE 31457280 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;

Tablespace altered.
  • Ouvrez l'accès à votre clone de base de données en verifiant qu'elle est enregistrée dans le listener, comme ci-dessous :
$ lsnrctl status listener

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 24-FEB-2008 23:42:44

Copyright (c) 1991, 2007, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.1.0.6.0 - Production
Start Date 21-FEB-2008 21:05:28
Uptime 3 days 2 hr. 37 min. 16 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/11.1.0/db_1/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/arkzoyd/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=arkzoyd)(PORT=1521)))
Services Summary...
Service "WHITE" has 1 instance(s).
Instance "WHITE", status READY, has 1 handler(s) for this service...
The command completed successfully
Constituer la base clone avec la méthode 2 :
  • Mettre à disposition, par exemple sur un nouveau point de montage, les fichiers de données clonées depuis l'environnement original et enregistrez-les dans le controlfile de la base de données originale. Pour ce faire, la méthode la plus simple consiste à monter le système de fichier sur l'environnement original. La commande RMAN correspondante est simplement CATALOG comme ci-dessous :
$ . oraenv
ORACLE_SID = [BLACK] ? BLACK

$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Mon Feb 25 22:31:18 2008

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

connected to target database: BLACK (DBID=330918259)

RMAN> catalog start with '/u01/app/oracle/oradata/WHITE';

searching for all files that match the pattern /u01/app/oracle/oradata/WHITE

List of Files Unknown to the Database
=====================================
File Name: /u01/app/oracle/oradata/WHITE/users01.dbf
File Name: /u01/app/oracle/oradata/WHITE/temp01.dbf
File Name: /u01/app/oracle/oradata/WHITE/undotbs01.dbf
File Name: /u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf
File Name: /u01/app/oracle/oradata/WHITE/system01.dbf
File Name: /u01/app/oracle/oradata/WHITE/sysaux01.dbf

Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u01/app/oracle/oradata/WHITE/users01.dbf
File Name: /u01/app/oracle/oradata/WHITE/temp01.dbf
File Name: /u01/app/oracle/oradata/WHITE/undotbs01.dbf
File Name: /u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf
File Name: /u01/app/oracle/oradata/WHITE/system01.dbf
File Name: /u01/app/oracle/oradata/WHITE/sysaux01.dbf
  • Vous pouvez envoyez l'arborescence des fichiers de données, ainsi que les fichiers d'archive logs entre les séquences notées au début et à la fin de l'opération de clone et le backup du controlfile sur le serveur de clone. Leur emplacement doit être identique ou au moins, vous devrez créer des liens symboliques pour qu'Oracle le croit [NDLR : Les liens, c'est pas la meilleure idée de ce post].

  • Créer un spfile et démarrer une nouvelle instance. Le plus simple peut-être de partir du spfile de votre base de données d'origine.
SQL> create pfile='/tmp/initWHITE.ora' from spfile;

[o Deplacez le fichier dans le $ORACLE_HOME/dbs sous Unix/Linux
ou %ORACLE_HOME%/database sous Windows sur le logiciel cible
o Modifiez le contenu du fichier en en particulier l'ensemble
des chemin pour convenir à votre clone ET CHANGEZ le paramètre
db_name pour qu'il corresponde au nouveau nom de votre base de
données, i.e. WHITE dans cet exemple
o Créez ce qu'il faut pour votre nouvelle instance Password
file (avec orapwd), service sous Windows (avec oradim),
/etc/oratab sous Linux...]
o Positionnez les paramètres db_file_name_convert et
log_file_name_convert pour qu'Oracle

$ cat /u01/app/oracle/product/10.2.0/db_1/dbs/initWHITE.ora

*.audit_file_dest='/u01/app/oracle/admin/WHITE/adump'
*.background_dump_dest='/u01/app/oracle/admin/WHITE/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/u01/app/oracle/oradata/WHITE/control01.ctl','/u01/app/oracle/oradata/WHITE/control02.ctl','/u01/app/oracle/oradata/WHITE/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/WHITE/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_file_name_convert='BLACK','WHITE'
*.log_file_name_convert='BLACK','WHITE'
*.db_name='WHITE'
*.db_recovery_file_dest_size=2147483648
*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
*.job_queue_processes=10
*.nls_length_semantics='BYTE'
*.open_cursors=300
*.pga_aggregate_target=25165824
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.resource_manager_plan=''
*.sga_target=167772160
*.undo_management='AUTO'
*.undo_retention=900
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/WHITE/udump'

$ mkdir -p /u01/app/oracle/admin/WHITE/adump
$ mkdir -p /u01/app/oracle/admin/WHITE/bdump
$ mkdir -p /u01/app/oracle/admin/WHITE/cdump
$ mkdir -p /u01/app/oracle/admin/WHITE/udump

$ . oraenv
ORACLE_SID = [WHITE] ? WHITE
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1

$ rman target=sys@black auxiliary=/

Recovery Manager: Release 10.2.0.4.0 - Production on Mon Feb 25 22:45:10 2008

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

connected to target database: BLACK (DBID=330918259)
connected to auxiliary database (not started)

RMAN> startup clone nomount;

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area 167772160 bytes

Fixed Size 1266392 bytes
Variable Size 109055272 bytes
Database Buffers 54525952 bytes
Redo Buffers 2924544 bytes

RMAN> sql clone 'create spfile from pfile';

sql statement: create spfile from pfile

RMAN> shutdown clone;

Oracle instance shut down

RMAN> startup clone nomount;

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area 167772160 bytes

Fixed Size 1266392 bytes
Variable Size 109055272 bytes
Database Buffers 54525952 bytes
Redo Buffers 2924544 bytes
  • Lancez la commande DUPLICATE :
RMAN> duplicate target database
to WHITE
nofilenamecheck
until sequence 35 thread 1;


Starting Duplicate Db at 25-FEB-08
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=156 devtype=DISK

contents of Memory Script:
{
set until scn 1031283;
set newname for datafile 1 to
"/u01/app/oracle/oradata/WHITE/system01.dbf";
set newname for datafile 2 to
"/u01/app/oracle/oradata/WHITE/undotbs01.dbf";
set newname for datafile 3 to
"/u01/app/oracle/oradata/WHITE/sysaux01.dbf";
set newname for datafile 4 to
"/u01/app/oracle/oradata/WHITE/users01.dbf";
set newname for datafile 5 to
"/u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf";
restore
check readonly
clone database
;
}
executing Memory Script

executing command: SET until clause

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting restore at 25-FEB-08
using channel ORA_AUX_DISK_1

datafile 1 is already restored to file /u01/app/oracle/oradata/WHITE/system01.dbf
datafile 2 is already restored to file /u01/app/oracle/oradata/WHITE/undotbs01.dbf
datafile 3 is already restored to file /u01/app/oracle/oradata/WHITE/sysaux01.dbf
datafile 4 is already restored to file /u01/app/oracle/oradata/WHITE/users01.dbf
datafile 5 is already restored to file /u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf
restore not done; all files readonly, offline, or already restored
Finished restore at 25-FEB-08
sql statement: CREATE CONTROLFILE REUSE SET DATABASE "WHITE" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 ( '/u01/app/oracle/oradata/WHITE/redo01.log' ) SIZE 50 M REUSE,
GROUP 2 ( '/u01/app/oracle/oradata/WHITE/redo02.log' ) SIZE 50 M REUSE,
GROUP 3 ( '/u01/app/oracle/oradata/WHITE/redo03.log' ) SIZE 50 M REUSE
DATAFILE
'/u01/app/oracle/oradata/WHITE/system01.dbf'
CHARACTER SET WE8ISO8859P15


contents of Memory Script:
{
switch clone datafile all;
}
executing Memory Script

released channel: ORA_AUX_DISK_1
datafile 2 switched to datafile copy
input datafile copy recid=1 stamp=647650246 filename=/u01/app/oracle/oradata/WHITE/undotbs01.dbf
datafile 3 switched to datafile copy
input datafile copy recid=2 stamp=647650246 filename=/u01/app/oracle/oradata/WHITE/sysaux01.dbf
datafile 4 switched to datafile copy
input datafile copy recid=3 stamp=647650246 filename=/u01/app/oracle/oradata/WHITE/users01.dbf
datafile 5 switched to datafile copy
input datafile copy recid=4 stamp=647650246 filename=/u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf

contents of Memory Script:
{
set until scn 1031283;
recover
clone database
delete archivelog
;
}
executing Memory Script

executing command: SET until clause

Starting recover at 25-FEB-08
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=159 devtype=DISK

starting media recovery

archive log thread 1 sequence 34 is already on disk as file /u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_25/o1_mf_1_34_3w70z6q8_.arc
archive log thread 1 sequence 35 is already on disk as file /u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_25/o1_mf_1_35_3w71204t_.arc
archive log filename=/u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_25/o1_mf_1_34_3w70z6q8_.arc thread=1 sequence=43
archive log filename=/u01/app/oracle/flash_recovery_area/BLACK/archivelog/2008_02_25/o1_mf_1_35_3w71204t_.arc thread=1 sequence=44
media recovery complete, elapsed time: 00:00:04
Finished recover at 25-FEB-08

contents of Memory Script:
{
change datafilecopy '/u01/app/oracle/oradata/WHITE/system01.dbf' uncatalog;
change datafilecopy '/u01/app/oracle/oradata/WHITE/undotbs01.dbf' uncatalog;
change datafilecopy '/u01/app/oracle/oradata/WHITE/sysaux01.dbf' uncatalog;
change datafilecopy '/u01/app/oracle/oradata/WHITE/users01.dbf' uncatalog;
change datafilecopy '/u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf' uncatalog;
}
executing Memory Script

uncataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/system01.dbf recid=20 stamp=647649298
Uncataloged 1 objects


uncataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/undotbs01.dbf recid=18 stamp=647649298
Uncataloged 1 objects


uncataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/sysaux01.dbf recid=21 stamp=647649298
Uncataloged 1 objects


uncataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/users01.dbf recid=17 stamp=647649298
Uncataloged 1 objects


uncataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf recid=19 stamp=647649298
Uncataloged 1 objects


contents of Memory Script:
{
shutdown clone;
startup clone nomount ;
}
executing Memory Script

database dismounted
Oracle instance shut down

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area 167772160 bytes

Fixed Size 1266392 bytes
Variable Size 109055272 bytes
Database Buffers 54525952 bytes
Redo Buffers 2924544 bytes
sql statement: CREATE CONTROLFILE REUSE SET DATABASE "WHITE" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 ( '/u01/app/oracle/oradata/WHITE/redo01.log' ) SIZE 50 M REUSE,
GROUP 2 ( '/u01/app/oracle/oradata/WHITE/redo02.log' ) SIZE 50 M REUSE,
GROUP 3 ( '/u01/app/oracle/oradata/WHITE/redo03.log' ) SIZE 50 M REUSE
DATAFILE
'/u01/app/oracle/oradata/WHITE/system01.dbf'
CHARACTER SET WE8ISO8859P15


contents of Memory Script:
{
set newname for tempfile 1 to
"/u01/app/oracle/oradata/WHITE/temp01.dbf";
switch clone tempfile all;
catalog clone datafilecopy "/u01/app/oracle/oradata/WHITE/undotbs01.dbf";
catalog clone datafilecopy "/u01/app/oracle/oradata/WHITE/sysaux01.dbf";
catalog clone datafilecopy "/u01/app/oracle/oradata/WHITE/users01.dbf";
catalog clone datafilecopy "/u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf";
switch clone datafile all;
}
executing Memory Script

executing command: SET NEWNAME

renamed temporary file 1 to /u01/app/oracle/oradata/WHITE/temp01.dbf in control file

cataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/undotbs01.dbf recid=1 stamp=647650258

cataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/sysaux01.dbf recid=2 stamp=647650258

cataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/users01.dbf recid=3 stamp=647650258

cataloged datafile copy
datafile copy filename=/u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf recid=4 stamp=647650258

datafile 2 switched to datafile copy
input datafile copy recid=1 stamp=647650258 filename=/u01/app/oracle/oradata/WHITE/undotbs01.dbf
datafile 3 switched to datafile copy
input datafile copy recid=2 stamp=647650258 filename=/u01/app/oracle/oradata/WHITE/sysaux01.dbf
datafile 4 switched to datafile copy
input datafile copy recid=3 stamp=647650258 filename=/u01/app/oracle/oradata/WHITE/users01.dbf
datafile 5 switched to datafile copy
input datafile copy recid=4 stamp=647650258 filename=/u01/app/oracle/oradata/WHITE/datafile/o1_mf_demo_3w6sr54o_.dbf

contents of Memory Script:
{
Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at 25-FEB-08
  • Votre clone de base de données est ouverte ; vérifiez qu'elle est enregistrée dans le listener, comme ci-dessous :
$ lsnrctl status listener

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 25-FEB-2008 22:59:03

Copyright (c) 1991, 2007, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.1.0.6.0 - Production
Start Date 21-FEB-2008 21:05:28
Uptime 4 days 1 hr. 53 min. 35 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/11.1.0/db_1/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/arkzoyd/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=arkzoyd)(PORT=1521)))
Services Summary...
Service "WHITE" has 1 instance(s).
Instance "WHITE", status READY, has 1 handler(s) for this service...
The command completed successfully
Conclusion

Peut-être un jour tout sera intégré et une commande unique permettra de présenter une instance clone de l'originale ; Si on rêvait, on dirait que ASM pourrait offrir une vue en lecture/écriture de la base originale comme NetApp Flexclone. En attendant, utilisez la commande DUPLICATE avec un BEGIN/END BACKUP permet de tirer parti de l'argent investi dans le stockage. En plus, c'est vraiment rapide, quoique, ce n'est pas la première idée qui vienne à l'esprit.

Oracle 10.2.0.4, DBUA et Capture d'Activité sur 10g pour Database Replay

10.2.0.4 est dehors (Sur Linux x86 32bits pour l'instant mais ça me suffit). Merci au blog de Laurent, le premier parmi les flux RSS auxquels je suis abonné à révéler cette info du 22 février. Aussitôt téléchargé, aussitôt appliqué...
$ . oraenv
ORACLE_SID = [BLACK] ? BLACK
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1

$ cd ~/distribs/6810189/Disk1

$ export DISTRIB=`pwd`

$ ./runInstaller -silent \
-responseFile $DISTRIB/response/patchset.rsp \
ORACLE_HOME=$ORACLE_HOME \
ORACLE_HOME_NAME=OraDb102Home1

Starting Oracle Universal Installer...

Checking installer requirements...

Checking operating system version: must be Ubuntu 7.10 Gutsy Gibbon
Passed

[...]

The installation of Oracle Database 10g Release 2 Patch Set 3 was successful.
Please check '/u01/app/oraInventory/logs/silentInstall2008-02-24_08-29-51PM.log'
for more details.

$ sudo /u01/app/oracle/product/10.2.0/db_1/root.sh

[...]

Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
Reste que j'utilise tous les outils en mode silent à l'exception de DBUA. Ne voilà-t-il pas l'occasion de lui laisser sa chance ? Pour en savoir plus, lancez l'aide de DBCA :
$ dbca -help
Ça a l'air bien plus simple que tous les autres assistants et installer. Faisons le test :
$ dbca -silent -sid BLACK           \
-backupLocation /u02/backup \
-recompile_invalid_objects true \
-degree_of_parallelism 1

[... et 40 min plus tard ]

Database upgrade has been completed successfully, and the database is ready to use.
100% complete
Check the log file "/u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/dbua/logs/silent.log" for upgrade details.
C'est terminé ! Il a redémarré la base de données, effectué une sauvegarde, appliqué les scripts, recompilé et redémarré l'instance en mode normal. Je suis vraiment épaté ! Reste à vérifier le fichier de log et DBA_REGISTRY
$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Sun Feb 24 21:06:57 2008

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> col COMP_NAME format a35
SQL> col VERSION format a12
SQL> col status format a7
SQL> set pages 100
SQL> select COMP_NAME, VERSION, STATUS
from dba_registry;

COMP_NAME VERSION STATUS
----------------------------------- ------------ -------
Oracle Database Catalog Views 10.2.0.4.0 VALID
Oracle Database Packages and Types 10.2.0.4.0 VALID
Oracle Workspace Manager 10.2.0.4.3 VALID
JServer JAVA Virtual Machine 10.2.0.4.0 VALID
Oracle XDK 10.2.0.4.0 VALID
Oracle Database Java Packages 10.2.0.4.0 VALID
Oracle Expression Filter 10.2.0.4.0 VALID
Oracle Data Mining 10.2.0.4.0 VALID
Oracle Text 10.2.0.4.0 VALID
Oracle XML Database 10.2.0.4.0 VALID
Oracle Rule Manager 10.2.0.4.0 VALID
Oracle interMedia 10.2.0.4.0 VALID
OLAP Analytic Workspace 10.2.0.4.0 VALID
Oracle OLAP API 10.2.0.4.0 VALID
OLAP Catalog 10.2.0.4.0 VALID
Spatial 10.2.0.4.0 VALID
Oracle Enterprise Manager 10.2.0.4.0 VALID
Je me demande si ça marche aussi bien avec RAC ! Enfin maintenant passons aux choses sérieuses, j'ai entendu dire qu'on pourrait capturer une activité sur 10g avec Database Replay et la jouer sur 11g...
SQL> desc DBMS_WORKLOAD_CAPTURE
[...]
Le package est là en tout cas ! Vous n'avez plus aucune excuse pour ne pas migrer en 11g maintenant. Regardez ce post d'il y a 6 mois déjà !

16 février 2008

Surfez moins, ne ratez rien : abonnez-vous aux sites Oracle !

Vous passez peut-être encore des heures sur Internet pour ne rien rater de ce qui se passe dans le monde Oracle : Oracle Technology Network, Oracle Magazine, le blog de Tom Kyte, AskTom, le blog de Jonathan Lewis, le blog de The Pythian Group et toutes les news de première, seconde ou troisième zone comme ce blog-ci.

Vous pourriez consacrer moins de 20 minutes par jour
à cette activité, et utiliser ce temps à des taches plus valorisantes, comme de lire l'intégralité de la documentation Oracle. C'est le principes des "News Feed". Vous ne vous connectez plus qu'à votre lecteur de flux. Google Search et Metalink, n'interviendront plus que lorsque vous aurez un problème.

J'utilise Google Reader. Ils expliquent mieux que je ne pourrais le faire ce qu'est un lecteur de flux ou agr
égateur (d'après WikiPedia). A vrai dire, il y en a des dizaines à commencer par Thunderbird, Firefox, MacOS ou les versions récentes de Windows (Enfin pour ce dernier, je l'ai juste entendu dire ;-) )

Pour ce blog, vous pouvez vous abonner, une fois que vous avez paramétré votre agr
égateur avec un des liens ci-dessous :

Le Blog

Les commentaires

Vous pouvez aussi utiliser votre email en ajoutant votre adresse ci-dessous :

Enter your email address:

Delivered by FeedBurner

Quand "kill -9" n'a plus aucun effet...

Vous vous connectez à un serveur et vous découvrez que plusieurs process utilisent 100% de CPU. Vous décidez d'y mettre un terme avec un "kill -9" et... rien : les process ne s'arrêtent pas ! Et ce sont de vrais process, pas des "defunct" ou une autre étrangeté. Savez-vous que ça peut arriver ? Que ces process peuvent être des process Oracle ? Que c'est arrivé à l'un d'entre-nous aujourd'hui ?

Je préfère quand on vient me voir après que le problème ait été réglé ; surtout avec la solution. Alors me voilà au milieu de cet imbroglio, pour reconstituer l'histoire du problème à travers tous les fichiers de trace et pour expliquer le comportement de RAC dans cette situation particulière, qui a raté son suicide malgré une tentative évidente.
  • L'OS est Linux RHEL4 x86_64 mais , j'imagine que ça pourrait aussi bien arriver sous Windows
  • La base de données Oracle 10.2.0.3 RAC mais ça n'a rien a voir avec, ni RAC, ni même Oracle
Vous trouverez la réponse dans le man de la commande "ps". Voici ci-dessous la ligne qui vous intéressera :
PROCESS STATE CODES
Here are the different values that the s, stat and state output
specifiers (header "STAT" or "S") will display to describe the state of
a process.
D Uninterruptible sleep (usually IO)
Quand un process fait certaines opérations, il devient ininterrompable, même par un "kill -9". C'est ce qu'on appelle le "D-State". Google donne quelques résultats intéressants notamment à propos de NFS. après quelques investigations, il apparaît que la couche SCSI est partie en live juste au moment de l'apparition du problème. Pourquoi ? J'aimerais avoir la réponse...

Le résultat est assez loin du monde idéal que l'on imagine. Hasard du calendrier, le multipath du noyau 2.6 est utilisé et Jeremy expliquait justement il y a 2 jours comment le configurer avec RHEL/OEL 5. Et RAC dans tout ça ? RAC n'a pas pu se suicider pourtant les autres noeuds savaient qu'il fallait le faire. C'est un de ces cas borderline, comme évoqué par Kirk McGowan l'an dernier à propos du STONITH (Le premier cas réel que je rencontre en 10.2) où RAC ne réagit pas beaucoup mieux qu'une single instance.

En fait pour résoudre ce problème, il n'y avait pas d'autre alternative que de rebooter le serveur ce qui a été fait dans les minutes qui ont suivi la découverte du problème. Voilà une preuve de plus que RAC n'est qu'une brique dans la mise en œuvre d'une solution hautement disponible et que la supervision a, elle ausi, son importance, même au 21e siècle.

11 février 2008

Un moteur de recherche pour Oracle

Juste un mot pour ce qui pourrait remplacer Google dans votre barre de recherche FireFox ou Internet Explorer. Oracle Safe Search est un moteur de recherche pour vous aider au quotidien à naviguer dans les informations relatives à Oracle.

Enjoy the web !

10 février 2008

Cloner une base de données sans sauvegarde en 11g

Remarque préliminaire :
Ce post suppose que vous utilisiez Oracle Database 11.1 ou supérieure. Les tests ont été réalisés avec une version 11.1.0.6 sur Linux Ubuntu et nécessiteront sans doute quelques ajustements pour une autre version ou un autre environnement. Quoiqu'il en soit, testez toujours une methode avant de l'appliquer à un de vos environnements.
Comme dans mon précédent post, j'ai cette chanson dans ma tête : "Comment cloner une base de données dans ASM ?". Voici une nouvelle tentative de réponse, cette fois avec la commande DUPLICATE de RMAN et sans passez par les étapes de sauvegarde ni de transport de la sauvegarde entre plusieurs serveurs... Nous nous appuyerons sur la clause FROM ACTIVE DATABASE de la commande RMAN DUPLICATE ; il s'agit d'une de ces nouveautés 11g.

Supposons pour faire simple que vous avez une base de données avec son instance BLUJ sur une machine blue et que vous vouliez créer une base de données REDX sur une machine red. Pour corser un peu l'affaire, et rendre possible la manipulation sur un seul serveur, disons que la base de données est dans le Disk Group DGBLUJ sur blue et que vous voulez la copier dans le Disk Group DGREDX sur red. Voilà pour les hypothèses ; maintenant, comment faire ?

Etape 1 : Créer l'environnement sur le serveur cible

Dans cette première étape, vous allez mettre en place quelques fichiers indispensables pour démarrer. Un des pré-requis pour utiliser la commande DUPLICATE FROM ACTIVE DATABASE est d'avoir une instance cible accessible (i.e démarrée en mode NOMOUNT) via un alias Oracle*Net, il faut donc évidemment :
  • Avoir le logiciel installé Oracle Database 11g ou supérieur sur votre serveur cible ; la même version que sur votre machine source
  • Avoir ASM démarré et le(s) Disk Group(s) cible(s) monté(s)
Une fois ces étapes de préparations effectuées, vous allez démarrer l'instance cible. Pour cela, il est d'abord conseillé d'ajouter une ligne pour votre instance dans /etc/oratab comme ci-dessous (Sous Windows, utilisez oradim) :
$ grep REDX /etc/oratab
REDX:/u01/app/oracle/product/11.1.0/db_1:N
Ensuite créez un fichier de mots de passe puisqu'il faudra vous connecter depuis la machine source alors que la base de données n'est pas ouverte. Utilisez la commande orapwd comme ci-dessous :
$ cd $ORACLE_HOME/dbs
$ orapwd file=orapwREDX password=change_on_install entries=5
$ history -c
Soyez attentif que le nom et l'emplacement du fichier de mot de passe depend du système d'exploitation. Enfin pour terminer, créez un fichier init.ora (le SPFILE sera créé par le DUPLICATE). Voici un exemple typique d'un tel fichier sous Linux (Si vous n'utilisez pas les huge pages, ce que je ne recommande pas)
$ cat initREDX.ora
memory_target=300M
processes=80
db_name='REDX'
remote_login_passwordfile='exclusive'
Remarquez bien que le positionnement de la variable ORACLE_BASE est désormais obligatoire avec 11g et que, du coup, vous n'avez besoin que de ces 4 paramètres pour démarrer votre instance. Etape que vous pouvez compléter comme ci-dessous :
$ . oraenv
ORACLE_SID = [+ASM] ? REDX
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1 is /u01/app/oracle

$ sqlplus / as sysdba

SQL> startup nomount
Etape 2: Configurer les accès réseaux

La commande DUPLICATE FROM ACTIVE DATABASE nécessite que la base de données source se connecte à la base de données cible et que des opérations telles que le démarrage et l'arrêt de l'instance soient effectuées à distance. Il est donc indispensable qu'il y ait un fichier de mots de passe sur les 2 environnements et que l'on puisse se connecter SYSDBA via le réseau. Il faut, en outre, que l'instance cible soit enregistrée de manière statique dans son listener et que le descripteur de connexion vers la cible utilise SID pour se connecter et non pas SERVICE_NAME.

Commençons par le listener sur la machine cible. Son fichier de configuration listener.ora doit ressembler à celui ci-dessous et comporter en particulier la clause SID_LIST_{LISTENER_NAME} qui permet d'enregistrer l'instance et son ORACLE_HOME de manière statique dans le listener.
$ cat listener.ora

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = red)(PORT = 1521))
)
)

SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1)
(SID_NAME=REDX)
)
)
Si vous utiliser des alias TNS stockés dans des fichiers tnsnames.ora, ce qui reste la méthode la plus courante malgré EZCONNECT, vos fichiers doivent contenir les alias pour la source et pour la cible ; le descripteur de votre cible doit contenir le mot clé SID comme ci-dessous :
$ cat tnsnames.ora
REDX=(DESCRIPTION=
(ADDRESS=(HOST=red)(PORT=1521)(PROTOCOL=TCP))
(CONNECT_DATA=(SID=REDX))
)
De cette manière, vous pouvez vous connecter à votre base cible par le réseau, même après l'avoir arrêtée :
$ . oraenv
ORACLE_SID = [+ASM] ? REDX
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1 is /u01/app/oracle

$ sqlplus / as sysdba

SQL> shutdown abort

SQL> connect sys@redx as sysdba

Connected to an idle instance.
Etape 3 : Derniers préparatifs sur l'environnement cible avant de démarrer l'opération.

Vérifiez les paramètres de votre environnement source et adaptez votre environnement cible en conséquence. Par exemple, dans mon cas, audit_dump_dest utilise $ORACLE_BASE/admin/BLUJ/adump. Je crée donc le répertoire correspondant (Ce n'est pas la peine de créer les répertoires de admin_dest, le système le fera seul) :
$ mkdir -p $ORACLE_BASE/admin/REDX/adump
Etape 4 : Cloner la base de données :

Et oui, ça ne fait que quelques minutes que vous avez démarrés et vous en êtes dejà à la conclusion. Connectez-vous à la base source (mot clé target) et la base cible (mot clé auxiliary) avec RMAN et démarrez la cible en mode nomount si ce n'est pas déjà le cas :
$ rman target=sys@bluj auxiliary=sys@redx

Recovery Manager: Release 11.1.0.6.0 - Production on Sun Feb 10 16:29:20 2008

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

connected to target database: BLUJ (DBID=1974909803)
connected to auxiliary database (not started)

RMAN> startup clone nomount;

Oracle instance started

Total System Global Area 209235968 bytes
Fixed Size 1298920 bytes
Variable Size 71306776 bytes
Database Buffers 134217728 bytes
Redo Buffers 2412544 bytes
Une fois l'opération effectuée, lancer la commande duplicate comme ci-dessous :
RMAN> DUPLICATE TARGET DATABASE
TO REDX
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT '+DGBLUJ','+DGREDX'
NOFILENAMECHECK
SPFILE
PARAMETER_VALUE_CONVERT '+DGBLUJ','+DGREDX','BLUJ','REDX'
SET LOG_FILE_NAME_CONVERT '+DGBLUJ','+DGREDX'
SET PGA_AGGREGATE_TARGET '80M'
SET SGA_TARGET '200M';
Quelques explications :
  • TO indique le nom de la base de données qui peut être différent de l'instance. A la fin de l'opération de restore/recover le duplicate renomme en effet la base de données.
  • FROM ACTIVE DATABASE indique que le duplicate n'utilise pas de backup mais envoie les fichiers de base de données par Oracle*Net à l'autre instance
  • DB_FILE_NAME_CONVERT permet de renommer les Disk Group lors de l'opération. Dans l'exemple, il n'y a qu'un mapping ( DGBLUJ devient DGREDX) mais vous pouvez en avoir plusieurs
  • NOFILENAMECHECK indique que les noms des fichiers seront différents entre la source et la cible. Nous sommes obligé d'utiliser cette clause avec DB_FILE_NAME_CONVERT
  • SPFILE indique que le SPFILE va être copie de l'environnement source et les mots clés suivants y sont attachés :
    • PARAMETER_VALUE_CONVERT permet de changer le contenu des paramètres du SPFILE en mettant en place des correspodances entre des chaînes de caractères (ici, DGBLUJ devient DGREDX et BLUJ devient REDX)
    • SET permet de positionner des paramètres en particulier pour ajouter des informations spécifiques à l'instance cible ou changer des valeurs existance sur l'instance source
    • LOG_FILE_NAME_CONVERT permet de modifier la destination des fichiers de Redo Log lorsque ceux-ci seront créés dans le fichier de contrôle.
Etape 5 : Visualiser le deroulement de l'opération.

Avec Linux ou Unix, utilisez VNC ou nohup ; l'exécution du DUPLICATE FROM ACTIVE DATABASE ressemble à ceci :
Starting Duplicate Db at 10-FEB-08
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=75 device type=DISK

contents of Memory Script:
{
backup as copy reuse
file '+DGBLUJ/bluj/spfilebluj.ora' auxiliary format
'/u01/app/oracle/product/11.1.0/db_1/dbs/spfileREDX.ora' ;
sql clone "alter system set spfile= ''/u01/app/oracle/product/11.1.0/db_1/dbs/spfileREDX.ora''";
}
executing Memory Script

Starting backup at 10-FEB-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=134 device type=DISK
Finished backup at 10-FEB-08

sql statement: alter system set spfile= ''/u01/app/oracle/product/11.1.0/db_1/dbs/spfileREDX.ora''

contents of Memory Script:
{
sql clone "alter system set db_name =
''REDX'' comment=
''duplicate'' scope=spfile";
sql clone "alter system set audit_file_dest =
''/u01/app/oracle/admin/REDX/adump'' comment=
'''' scope=spfile";
sql clone "alter system set control_files =
''+DGREDX/bluj/controlfile/current.267.646310763'', ''+DGREDX/bluj/controlfile/current.268.646310765'' comment=
'''' scope=spfile";
sql clone "alter system set db_create_file_dest =
''+DGREDX'' comment=
'''' scope=spfile";
sql clone "alter system set db_recovery_file_dest =
''+DGREDX'' comment=
'''' scope=spfile";
sql clone "alter system set dispatchers =
''(PROTOCOL=TCP) (SERVICE=REDXXDB)'' comment=
'''' scope=spfile";
sql clone "alter system set log_archive_dest_1 =
''location=+DGREDX'' comment=
'''' scope=spfile";
sql clone "alter system set LOG_FILE_NAME_CONVERT =
''+DGBLUJ'', ''+DGREDX'' comment=
'''' scope=spfile";
sql clone "alter system set PGA_AGGREGATE_TARGET =
80M comment=
'''' scope=spfile";
sql clone "alter system set SGA_TARGET =
200M comment=
'''' scope=spfile";
shutdown clone immediate;
startup clone nomount ;
}
executing Memory Script

sql statement: alter system set db_name = ''REDX'' comment= ''duplicate'' scope=spfile

sql statement: alter system set audit_file_dest = ''/u01/app/oracle/admin/REDX/adump'' comment= '''' scope=spfile

sql statement: alter system set control_files = ''+DGREDX/bluj/controlfile/current.267.646310763'', ''+DGREDX/bluj/controlfile/current.268.646310765'' comment= '''' scope=spfile

sql statement: alter system set db_create_file_dest = ''+DGREDX'' comment= '''' scope=spfile

sql statement: alter system set db_recovery_file_dest = ''+DGREDX'' comment= '''' scope=spfile

sql statement: alter system set dispatchers = ''(PROTOCOL=TCP) (SERVICE=REDXXDB)'' comment= '''' scope=spfile

sql statement: alter system set log_archive_dest_1 = ''location=+DGREDX'' comment= '''' scope=spfile

sql statement: alter system set LOG_FILE_NAME_CONVERT = ''+DGBLUJ'', ''+DGREDX'' comment= '''' scope=spfile

sql statement: alter system set PGA_AGGREGATE_TARGET = 80M comment= '''' scope=spfile

sql statement: alter system set SGA_TARGET = 200M comment= '''' scope=spfile

Oracle instance shut down

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area 209235968 bytes

Fixed Size 1298920 bytes
Variable Size 71306776 bytes
Database Buffers 134217728 bytes
Redo Buffers 2412544 bytes
RMAN-05529: WARNING: DB_FILE_NAME_CONVERT resulted in invalid ASM names; names changed to disk group only.

contents of Memory Script:
{
set newname for datafile 1 to
"+dgredx";
set newname for datafile 2 to
"+dgredx";
set newname for datafile 3 to
"+dgredx";
set newname for datafile 4 to
"+dgredx";
backup as copy reuse
datafile 1 auxiliary format
"+dgredx" datafile
2 auxiliary format
"+dgredx" datafile
3 auxiliary format
"+dgredx" datafile
4 auxiliary format
"+dgredx" ;
sql 'alter system archive log current';
}
executing Memory Script

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting backup at 10-FEB-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=+DGBLUJ/bluj/datafile/system.277.646310619
output file name=+DGREDX/redx/datafile/system.269.646333827 tag=TAG20080210T171025 RECID=0 STAMP=0
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:36
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=+DGBLUJ/bluj/datafile/sysaux.276.646310623
output file name=+DGREDX/redx/datafile/sysaux.268.646333925 tag=TAG20080210T171025 RECID=0 STAMP=0
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:05
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=+DGBLUJ/bluj/datafile/undotbs1.275.646310625
output file name=+DGREDX/redx/datafile/undotbs1.267.646333989 tag=TAG20080210T171025 RECID=0 STAMP=0
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=+DGBLUJ/bluj/datafile/users.274.646310625
output file name=+DGREDX/redx/datafile/users.266.646333991 tag=TAG20080210T171025 RECID=0 STAMP=0
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
Finished backup at 10-FEB-08

sql statement: alter system archive log current
sql statement: CREATE CONTROLFILE REUSE SET DATABASE "REDX" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 ( '+dgredx', '+dgredx' ) SIZE 50 M REUSE,
GROUP 2 ( '+dgredx', '+dgredx' ) SIZE 50 M REUSE,
GROUP 3 ( '+dgredx', '+dgredx' ) SIZE 50 M REUSE
DATAFILE
'+DGREDX/redx/datafile/system.269.646333827'
CHARACTER SET WE8ISO8859P15


contents of Memory Script:
{
backup as copy reuse
archivelog like "+DGBLUJ/bluj/archivelog/2008_02_10/thread_1_seq_7.272.646333995" auxiliary format
"+DGREDX" ;
catalog clone recovery area;
switch clone datafile all;
}
executing Memory Script

Starting backup at 10-FEB-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=7 RECID=8 STAMP=646333995
output file name=+DGREDX/redx/archivelog/2008_02_10/thread_1_seq_7.262.646333999 RECID=0 STAMP=0
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01
Finished backup at 10-FEB-08

searching for all files in the recovery area

List of Files Unknown to the Database
=====================================
File Name: +dgredx/REDX/ARCHIVELOG/2008_02_10/thread_1_seq_7.262.646333999
File Name: +dgredx/REDX/DATAFILE/SYSAUX.268.646333925
File Name: +dgredx/REDX/DATAFILE/UNDOTBS1.267.646333989
File Name: +dgredx/REDX/DATAFILE/USERS.266.646333991
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: +dgredx/REDX/ARCHIVELOG/2008_02_10/thread_1_seq_7.262.646333999
File Name: +dgredx/REDX/DATAFILE/SYSAUX.268.646333925
File Name: +dgredx/REDX/DATAFILE/UNDOTBS1.267.646333989
File Name: +dgredx/REDX/DATAFILE/USERS.266.646333991

List of files in Recovery Area not managed by the database
==========================================================
File Name: +DGREDX/redx/controlfile/current.256.646333997
RMAN-07527: Reason: File was not created using DB_RECOVERY_FILE_DEST initialization parameter
File Name: +DGREDX/redx/datafile/system.269.646333827
RMAN-07527: Reason: File was not created using DB_RECOVERY_FILE_DEST initialization parameter

number of files not managed by recovery area is 2, totaling 9.59MB

datafile 2 switched to datafile copy
input datafile copy RECID=4 STAMP=646334001 file name=+DGREDX/redx/datafile/sysaux.268.646333925
datafile 3 switched to datafile copy
input datafile copy RECID=5 STAMP=646334001 file name=+DGREDX/redx/datafile/undotbs1.267.646333989
datafile 4 switched to datafile copy
input datafile copy RECID=6 STAMP=646334001 file name=+DGREDX/redx/datafile/users.266.646333991

contents of Memory Script:
{
set until scn 547574;
recover
clone database
delete archivelog
;
}
executing Memory Script

executing command: SET until clause

Starting recover at 10-FEB-08
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=148 device type=DISK

starting media recovery

archived log for thread 1 with sequence 7 is already on disk as file +DGREDX/redx/archivelog/2008_02_10/thread_1_seq_7.262.646333999
archived log file name=+DGREDX/redx/archivelog/2008_02_10/thread_1_seq_7.262.646333999 thread=1 sequence=7
media recovery complete, elapsed time: 00:00:01
Finished recover at 10-FEB-08

contents of Memory Script:
{
shutdown clone immediate;
startup clone nomount ;
}
executing Memory Script

database dismounted
Oracle instance shut down

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area 209235968 bytes
Fixed Size 1298920 bytes
Variable Size 71306776 bytes
Database Buffers 134217728 bytes
Redo Buffers 2412544 bytes
sql statement: CREATE CONTROLFILE REUSE SET DATABASE "REDX" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 ( '+dgredx', '+dgredx' ) SIZE 50 M REUSE,
GROUP 2 ( '+dgredx', '+dgredx' ) SIZE 50 M REUSE,
GROUP 3 ( '+dgredx', '+dgredx' ) SIZE 50 M REUSE
DATAFILE
'+DGREDX/redx/datafile/system.269.646333827'
CHARACTER SET WE8ISO8859P15


contents of Memory Script:
{
set newname for tempfile 1 to
"+dgredx";
switch clone tempfile all;
catalog clone datafilecopy "+DGREDX/redx/datafile/sysaux.268.646333925";
catalog clone datafilecopy "+DGREDX/redx/datafile/undotbs1.267.646333989";
catalog clone datafilecopy "+DGREDX/redx/datafile/users.266.646333991";
switch clone datafile all;
}
executing Memory Script

executing command: SET NEWNAME

renamed tempfile 1 to +dgredx in control file

cataloged datafile copy
datafile copy file name=+DGREDX/redx/datafile/sysaux.268.646333925 RECID=1 STAMP=646334024

cataloged datafile copy
datafile copy file name=+DGREDX/redx/datafile/undotbs1.267.646333989 RECID=2 STAMP=646334024

cataloged datafile copy
datafile copy file name=+DGREDX/redx/datafile/users.266.646333991 RECID=3 STAMP=646334024

datafile 2 switched to datafile copy
input datafile copy RECID=1 STAMP=646334024 file name=+DGREDX/redx/datafile/sysaux.268.646333925
datafile 3 switched to datafile copy
input datafile copy RECID=2 STAMP=646334024 file name=+DGREDX/redx/datafile/undotbs1.267.646333989
datafile 4 switched to datafile copy
input datafile copy RECID=3 STAMP=646334024 file name=+DGREDX/redx/datafile/users.266.646333991

contents of Memory Script:
{
Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at 10-FEB-08
Conclusion

C'est vraiment très simple, non ? D'autant plus que vous pouvez fixer le parallélisme ou les taux d'IO sur les différents canaux et donc réellement maitriser les temps de duplication. Il ne manque peut-être que de compresser pour envoyer par le réseau mais je devine que RMAN nous prépare encore d'autres surprises dans les versions à venir. D'ici là il est toujours possible de déplacer le(s) Disk(s) Group(s) sur le serveur source le temps de constituer le clone.

09 février 2008

Copier une base de données avec DBCA

Remarque préliminaire :
Les tests décrits dans ce post ont été réalisés sur Linux avec Oracle 10.1.0.6. Il est probable que les syntaxes nécessitent d'être adaptées en fonction de la version d'Oracle et du système d'exploitation utilisé.

2nd r
emarque préliminaire :
Vérifiez que votre base de données est en mode archivelog et testez la procédure avant de l'utiliser en production... Il se pourrait bien que les accès
à votre base de données source soient compromis à un moment de la procédure !
Il y a quelques jours, on m'a demandé comment copier une base de données d'un DiskGroup ASM situé sur un serveur à un autre. Depuis ça trotte dans ma tête comme une chanson ringarde qu'on entend à la radio le matin et dont on n'arrive plus à se débarrasser. Sauf qu'en plus, après 2 matins, la question est toujours là : Comment faire ?
  • "RMAN DUPLICATE" parait la réponse la plus évidente ; Enfin, si (a) vous pouvez accédez aux 2 serveurs simultanément avec RMAN et si (b) vous pouvez utiliser un espace de stockage des sauvegardes sur disques qui a le même nom des deux cotés (qu'il soit partagé ou non). A propos de (b), si avez des bandes ou que vous utilisez "from active database" d'Oracle 11g, ce n'est pas obligatoire !
  • "RMAN RESTORE & RECOVER" est une solution qui fonctionne dans tous les cas et qui offre le terrible avantage, en plus de ne pas nécessiter de connexion réseau entre vos serveurs source et cible, de valider que vous serez capable le cas échéant de restaurer votre base de données sur un autre serveur.
  • "RMAN BACKUP AS COPY" peut également, élégamment, remplacer la commande cp que vous feriez habituellement puisqu'en outre, il n'est pas nécessaire de passer votre base de données en mode BACKUP (BEGIN/END)
  • La bonne vieille méthode du mode BACKUP (BEGIN/END) fonctionne aussi. Vous pourrez sans doute remplacer le "cp" par ftp ou WebDAV, ce que je ne m'aventurerai pas à faire sur autre chose qu'une demo. Vous pourrez surtout utiliser ce mode avec un mécanisme de copie ou de snapshot au niveau du stockage (EMC BCV, NetApp SnapClone, ...). Dans ce dernier cas, pas le plus inintéressant, vous copierez le Disk Group complet. Allez voir cet article Alejandro Vargas à propos d'ASM et des BCV mais qui s'applique à toute une palette de technologies de stockage. J'imagine que cet article à un petit frère sur Metalink.
Revenons à la chanson ringarde que j'ai dans la tête depuis 3 jours : (La mélodie) Comment faire des tests sur mon desktop Ubuntu Gutsy Gibbon ? Merci à Dave Edwards qui m'a aidé, encore une fois, dans l'élaboration de la réponse à cette question sur ce post de mon autre blog ! (Le solo de batterie) Est-il possible de renommer un Disk Group et remonter le BCV dans la même instance ASM ? Alejandro Vargas répond catégoriquement non en 10g mais s'il existe un moyen en 11g, je trouverai ! (Les paroles) Existe-t-il une autre méthode pour copier une base de données ? La réponse est "oui" et c'est même la méthode la plus simple que je connaisse, même si, comme les autres, elle a ses limites : "Vous pouvez utiliser les capacités de création d'un clone de base de données de DBCA !"

Pour commencer et pour mieux appréhender Oracle Database Configuration Assistant (DBCA) , vous pouvez configurer votre environnement Oracle et lancer la commande qui suit :
dbca -h
Pour copier votre base de données d'un environnement ASM à un autre environnement distinct, vous allez :
  1. Créer un template de votre base de données; DBCA utilisera alors de manière cachée RMAN, sans arrêter la base de données, pour constituer l'ensemble des fichiers du template
  2. Déplacer votre template d'un serveur à un autre par le moyen de votre choix (NFS, ftp/scp, umount/mount d'un système de fichier, ...)
  3. Créer une base de données à partir de votre template
Etape 1 : Créer un template de votre base de données

Nous supposerons que vous avez créé un répertoire /source/template pour stocker la copie de votre base de données et que votre base de données source s'appelle BLUJ. Positionnez l'environnement Oracle correspondant à celui de la base de données et lancez DBCA comme ci-dessous :
$ dbca -silent -createCloneTemplate    \
-sourceSID BLUJ \
-templateName BLUJ_template \
-sysDBAPassword change_on_install \
-maintainFileLocations false \
-datafileJarLocation /source/template
La chaîne de caractère qui suit "-templateName" est le nom du template qui sera généré. Choisissez celui qui vous contient et notez le bien puisqu'il sera réutilisé lors de la création de la base de données sur votre cible. "-sysDBAPassword" indique le mot de passe de l'utilisateur SYS (ou d'un autre SYSDBA si vous utiliser en outre "-sysDBAUserName"). Utilisez "-maintainFileLocations false" pour pouvoir déplacer les fichiers dans un autre Disk Group sur votre cible.

Lorsque vous exécutez la commande (Utilisez nohup !), le résultat ressemble à ce qui suit :
Gathering information from the source database
4% complete
8% complete
13% complete
17% complete
22% complete
Backup datafiles
28% complete
88% complete
Creating template file
100% complete
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/silent9.log" for further details.
3 fichiers sont générés :
  • un fichier xml [templateName].dbc (i.e. BLUJ_template.dbc dans ce cas) situé dans $ORACLE_HOME/assistants/dbca/templates. Ce fichier contient la description du template
  • un fichier de contrôle [templateName].ctl situé dans /source/template
  • un fichier [templateName].dfb situé dans /source/template qui contient les fichiers de données de votre base de données source.
Etape 2 : Déplacer votre template d'un serveur à un autre

Vous avez le choix des armes ! Pour simplifier, nous dirons simplement que vous copiez l'ensemble des fichiers générés dans /source/template dans /cible/template et que vous copiez le fichier BLUJ_template.dbc dans le répertoire $ORACLE_HOME/assistants/dbca/templates que vous allez utiliser pour la cible.
Note :
C'est évident mais ça va mieux en le disant que la version du logiciel de base de données et que le système d'exploitation doivent être identiques entre la source et la cible.
Etape 3 : Créer une base de données à partir de votre template

Nous supposerons que le logiciel de base de données est installé sur votre machine cible. ASM est démarré et un Disk Group DGREDX est monté pour accueillir la copie de votre base de données. Nous appellerons la base de données cible REDX pour cet exemple
$ dbca -silent -createDatabase           \
-templateName BLUJ_template.dbc \
-gdbName REDX \
-sysPassword change_on_install \
-systemPassword manager \
-datafileJarLocation /cible/template \
-storageType ASM \
-asmSysPassword change_on_install \
-diskGroupName DGREDX \
-totalMemory 250
La chaîne de caractère qui suit "-templateName" est le nom du template généré à l'étape 1. "-sysPassword" et "-systemPassword" indiquent les mots de passe de SYS et SYSTEM. "-datafileJarLocation" indique l'emplacement des fichiers du template ; ce paramètre n'est pas nécessaire si vous laissez les 2 fichiers dans le même endroit. "-asmSysPassword" indique le mot de passe de l'utilisateur SYS d'ASM tandis que "-diskGroupName" indique le DiskGroup dans lequel la base de données sera créée. "-totalMemory" indique la valeur de MEMORY_TARGET en Mega Octets et est une nouvelle option de 11g.

Lorsque vous exécutez la commande (Utilisez nohup), le résultat ressemble à ce qui suit :
Copying database files
1% complete
3% complete
37% complete
Creating and starting Oracle instance
40% complete
45% complete
50% complete
55% complete
56% complete
57% complete
60% complete
62% complete
Completing Database Creation
66% complete
70% complete
73% complete
77% complete
88% complete
100% complete
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/REDX/REDX0.log" for further details.
Vous pouvez ensuite adapter le paramétrage à vos besoins. Vous vérifierez que les fichiers ont été créés dans ASM en interrogeant le dictionnaire de REDX :
$ source oraenv
ORACLE_SID = [REDX] ?
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1 is /u01/app/oracle

$ sqlplus / as sysdba

SQL> select file_name
from dba_data_files;

FILE_NAME
-----------------------------------------
+DGREDX/redx/datafile/users.261.646254099
+DGREDX/redx/datafile/undotbs1.260.646254099
+DGREDX/redx/datafile/sysaux.259.646254097
+DGREDX/redx/datafile/system.258.646254091
Conclusion

C'est, sans doute, la manière la plus simple de copier une base de données sans l'arrêter. C'est particulièrement adapté si votre base de données cible est un RAC puisque DBCA pourra, en outre, faire toute la configuration des instances en collaboration avec le clusterware. Pour ce qui est des limites, il ne semble pas possible en mode ligne de commande de positionnez les fichiers dans des Disk Group distinct et surtout, je n'ai trouvé aucun moyen de changer le parallélisme pour constituer le template et le restituer. Enfin, les capacités de DBCA restent assez obscures malgré tous mes efforts. Si vous savez comment maîtriser ses options ou où trouver la doc associée, faites-moi un signe !

PS: Vous pouvez tout faire en mode graphique si vous préférez utiliser le mulot

PS2 : Si vous voulez vous amuser et faire des tests en série, voici une autre commande très utile :
dbca -silent -deleteDatabase           \
-sourceDB REDX \
-sysDBAPassword change_on_install

08 février 2008

Créer un pipe Unix entre 2 serveurs

Soyons clair, ce qui suit est loin d'avoir la pureté de AQ, JMS ou même d'une socket TCP. C'est beaucoup moins robuste aussi ! Mais, s'il vous arrive de lancer des programmes sur plusieurs serveurs Unix/Linux simultanément et que vous voulez suivre l'évolution de tous ces programmes, sans vous casser la tête, vous pouvez simplement transporter les données d'un pipe nommé sur une machine au stdout ou un autre pipe nommé sur une autre machine :

Avant de lancer vos programmes
  • Créez un pipe nommé sur vos machines qui émettront les informations avec la commande mknod
server1$ mknod /tmp/server1 p
server2$ mknod /tmp/server2 p
  • Il faut que vous ayez une configuration ssh correcte (daemons, clés publiques et clés privées) sur chacun des serveurs. Vous voudrez pouvoir faire un ssh depuis le serveur qui affiche les données vers les serveurs qui les émettent sans que vous ayez à entrer un mot de passe. Pour cela, enregistrez les clés publiques de l'utilisateur de machine sur laquelle vous allez afficher le résultat dans les fichiers dans les fichiers ~/.ssh/authorized_keys des machines émettrices.
server1$ ssh server3 "cat ~/.ssh/id_dsa.pub" >> ~/.ssh/authorized_keys
user3@server3's password :
server1$ ssh server3 "cat ~/.ssh/id_rsa.pub" >> ~/.ssh/authorized_keys
user3@server3's password :
server2$ ssh server3 "cat ~/.ssh/id_dsa.pub" >> ~/.ssh/authorized_keys
user3@server3's password :
server2$ ssh server3 "cat ~/.ssh/id_rsa.pub" >> ~/.ssh/authorized_keys
user3@server3's password :
  • Lancer les commandes ssh sur le serveur d'affichage de sorte qu'elles dépilent les informations des pipes des serveur émetteurs et les affichent sur le stdout :
server3$ nohup ssh server1 "while true;do cat /tmp/server1; done" &
server3$ nohup ssh server2 "while true;do cat /tmp/server2; done" &
Remarques :
Vous pouvez rediriger le contenue des pipes des serveurs émetteurs vers un fichiers sur server3 ou vers un fichier avec ">>" comme ceci :
server3$ nohup ssh server1 "while true;do cat /tmp/server1; done" >>output.log &
Vous pouvez également utiliser "| tee" pour afficher simultanément les contenus à l'écran et dans un fichier ou un autre pipe.

Lancer les programmes sur vos machines émettrices

Il ne reste plus qu'à lancer vos programmes sur les serveurs émetteurs et à envoyer les sorties sur les pipes nommés locaux. Pour une démonstration simple, vous pouvez, par exemple utilisez echo :
server1$ echo "test" >/tmp/server1
Le mot test doit s'afficher sur l'écran du serveur récepteur.

Arrêter tout...

Sur le serveur récepteur, visualisez les ssh en cours et arrêtez-les avec la commande kill -9 comme ci-dessous :
server3$ $ ps -ef |grep [s]sh|grep while
user3 19147 18715 0 23:01 pts/1 00:00:00 ssh user1@server1 while t...
server3$ kill -9 19147
Au fait, à cause de la boucle, "while true", vous pouvez éventuellement perdre des messages aussi alors utilisez cette technique quand ça a du sens.

Message personnel :
"pipe sh" = futur problème !

07 février 2008

Qui achètera Sybase ?

Dommage, je ne l'ai pas ajouté à mes signets ! Je lisais un article d'un analyste qui annonçait que le temps des grosses fusions dans les sociétés de logiciels était bientôt terminé. En regardant les valeurs du secteurs d'après Reuters, on peut y croire... Quoique :
  • Auriez-vous imagine Sun acheter MySQL ? Microsoft acheter Yahoo ?
  • Ils dépensent des milliards de dollars depuis des années et comment vont-ils faire maintenant ? Acheter des centaines de sociétés plus petites tous les ans ? Pas étonnant que MySQL AB ait coûté si cher !
Il parait évident que de toute façon, le glas des plus "petits" a, plus que jamais, sonné. Quelques-uns des Teradata, Informatica, MicroStrategy, Netezza ou Sybase, puisque le BI a été une cible privilégiée récemment, devraient donc tomber en 2009. Dommage que je ne sois pas déjà riche, je ferais comme Carl Icahn ;-) !

Dans ce tourbillon, vous pouvez relever une nouvelle intéressante sur un site de SYBASE : ASE 15 aura pourra fonctionner "à la RAC". Au delà de l'hommage appuyé à ce qui fait notre quotidien (C'est toujours mieux quand ce sont vos compétiteurs qui le disent !), on peut imaginer que c'est aussi un excellent motif de rachat par Microsoft, toujours à ajouter des délais (en 2005, en 2008) à la prochaine version de son RDBMS et qui manque dans ce domaine de vrai "breaking news" ! Mais comme ils se jalousent tous, ça pourrait tout aussi bien être un autre... Les actionnaires de SYBASE pourraient-ils être les prochains à se féliciter ?

05 février 2008

X$ utilisées par les vues V$

Préférez-vous contruire des requêtes sur les tables X$ plutôt que sur les vues V$ ? Voila pourquoi vous faites ça :
  • "kgcl" est beaucoup plus facile à retenir que "file_name" ; après tout, il y a 5 lettres de moins !
  • Les vues V$ ne sont pas performantes. Oracle ne vous fournit ces vues que pour que vous ne consommiez toujours plus de CPU et ainsi gagner beaucoup plus d'argent. D'ailleurs Oracle est obligé de résoudre toutes les vues pour résoudre vos requêtes.
  • C'est quand même cool de pouvoir réviser ses requêtes à chaque patch. En effet, la condition "where kgcl in ('zX','Fs','Ba')" de votre requête n'envisage pas le fix de 5823456 que vous devez appliquer.
  • Vous cherchez à m'embrouiller...
Voilà plusieurs bonnes nouvelles : (1) pas besoin d'utiliser X$ pour m'embrouiller ; (2) Ces vues peuvent être mise à contribution pour révéler des informations passionnantes. Regardez ce que Luca Canali à propos d'ASM ou Alex Gorbachev à propos du BCTF en font ; (3) Si vous descendez jusqu'à la cause première de nombreux bugs, vous arrivez à une table X$.

Alors si vous ne connaissez pas les requêtes associées aux vues V$, je vous propose d'exécuter le script SQL ci-dessous :
set pages 1000

accept v_view default 'V$SESSION' prompt "Enter the V$ View [V$SESSION] : "

select VIEW_DEFINITION
from V$FIXED_VIEW_DEFINITION
where VIEW_NAME=upper('G&v_view');
Remarquez qu'il faut en fait interroger le contenu des vues "GV$" et pas "V$" pour connaitre les tables X$ associées. Une preuve de plus que RAC est partout.

Au fait, si vous n'utilisez pas les tables X$, tous les jours, continuez !

03 février 2008

Comment trouver les bonnes options de l'installer Oracle ?

Souvent l'expérience et la lecture des fichiers .rsp fournis avec le logiciel suffisent. Dans certains cas, au contraire, l'information n'est disponible dans aucun fichier. C'est le cas notamment pour installer les agents GridControl en cluster, probablement parce que la méthode préconisée s'appuie sur le script agentDownload.

Toutefois, HTTP n'étant plus accessible depuis mon GridControl (cf Grid Control, Agent 10g et HTTPS restreint à 443 ), je n'arrive pas à installer les agents avec agentDownload ! Par contre, j'arrive à les configurer manuellement une fois le logiciel installé. Mais comment installer le logiciel dans ces conditions ? Avec runInstaller ?

Le problème du mode graphique, c'est que ça prend de longues minutes de faire passer le protocole X11 dans 2 tunnels successifs :
ssh -R 7777:localhost:7000 gateway-server
ssh -R 7001:localhost:7777 target-server
Sans compter les coupures réseaux ou que dans certains cas, non seulement x11 forwarding est bloqué, mais en plus tous les ports non-occupés sont bloqués, même sur localhost. Le mode "silent" est donc un vrai bonheur, à condition de connaître les options à utiliser.

Quand vous ne connaissez pas la syntaxe, il suffit de lancer le mode graphique de l'installeur en enregistrant les options sélectionnées dans votre propre fichier de réponse comme ci-dessous :
export DISPLAY=localhost:1
./runInstaller -record -destinationFile /tmp/myagent.rsp
. Reste alors a utiliser le mode graphique "comme avant...".

L'option que je cherchais était tout simplement CLUSTER_NODES={"node1","node2"}. J'aurais du m'en douter !

Automatiser Oracle Grid Control 10g avec EMCLI

Je ne crois pas qu'il soit très utile d'entrer dans le détail, mais en gros j'ai passé cette semaine à démantibuler et reconstruire par morceaux un RAC 10 noeuds, histoire de changer plusieurs éléments de l'infrastructure technique et logicielle, d'appliquer les derniers Patch Set et CPU. En ligne de commande, vous l'auriez deviné et en réduisant l'indisponibilité à sa (presque !) plus simple expression ! En dehors d'une grosse surprise avec le filer NetApp lors de l'upgrade de la base de données, tout c'est passé à merveille...

Le temps est venu de supprimer l'ancienne configuration du Grid Control (10.2.0.4), c'est à dire :
  • 10 instances
  • 1 cluster de base de données
  • 10 listeners
  • 1 cluster
  • 10 serveurs
  • 10 agents
A la 5eme instance, vous vous dites : "Je ne perdrais sûrement pas mon temps à regarder comment faire la même chose en ligne de commande avec emcli !". J'aime bien le GridControl et surtout les packs Diagnostic et Tuning ! Mais, pour certaines opérations, il faut avouer que le web, même 2.0, n'égale pas toujours le mode ligne de commande.

Et non, vous ne perdrez pas votre temps ! Pour plus d'informations, reportez-vous à la documentation de emcli intitulée Oracle® Enterprise Manager Command Line Interface . Si vous voulez un cas d'utilisation simple, voici comment supprimer des cibles de votre Grid Control avec EMCLI...

Etape 1 : Installer "emcli"


Emcli s'utilise à distance. Autement dit, vos commandes sont transmises au GridControl via HTTP ou HTTPS. Pour télécharger emcli, nous supposerons que https://host:port/em est l'URL du Grid Control que vous utilisez. Il suffit alors de naviguer vers https://host:port/em/console/emcli/download . Les instructions sont disponibles depuis cette page.

Dans un premier temps, une fois le fichier emclikit.jar téléchargé, positionnez les variables JAVA_HOME et PATH pour accéder à une version du JDK 1.4.2 ou supérieure ( utilisez des commandes équivalentes avec la console Windows, e.g. set PATH=%JAVA_HOME%\bin;%PATH%) :
# Modifier la valeur de JAVA_HOME selon
# votre environnement
$ export JAVA_HOME=/opt/local/jdk1.5_02

$ export PATH=$JAVA_HOME/bin:$PATH:.
Quand l'environnement positionné, créez un répertoire et installez emcli a l'aide des commandes suivantes
# Changez le nom du répertoire selon vos besoins :
$ mkdir ~/emcli
$ java -jar emclikit.jar client -install_dir=~/emcli
$ cd ~/emcli
Etape 2 : Configurer "emcli"

Vous pouvez ensuite utiliser la commande "emcli" et visualiser les différents arguments associés :
$ emcli help

Summary of commands:

argfile -- execute emcli verb where verb and arguments are contained in a file
help -- get help using emcli
setup -- setup emcli to work with an EM management server (OMS)
sync -- synchronize the emcli client with an OMS

Management Plug-in Verbs
add_group_to_mpa -- add a group to a Management Plug-in Archive
add_mp_to_mpa -- add a Management Plug-in to a Management Plug-in Archive
Avant de lancer des opérations sur le Grid Control avec emcli, vous devez configurer le client. Cela consiste à enregistrer l'URL et les informations d'accès au GridControl. La commande ci-dessous permet de d'enregistrer les informations de connexion au GridControl https://host:443/em :
$ cd ~/emcli
$ mkdir store
$ emcli setup -url="https://host:443/em" \
-username=SYSMAN \
-dir=~/emcli/store

Oracle Enterprise Manager 10g Release 10.2.0.4.0.
Copyright (c) 1996, 2007 Oracle Corporation. All rights reserved.

Enter password:

[...]
--------------------------------------
Do you trust the certificate chain? [yes/no] yes
Etape 3 : Utiliser "emcli" :

Vous pouvez ensuite utiliser emcli pour effectuer des opérations en mode ligne de commande comme ci-dessous :
$ emcli get_targets

Status Status Target Type Target Name
ID
0 Down cluster my-cluster
0 Up host node1
0 Up host node2
[...]
0 Up oracle_database rac1
0 Up oracle_database rac2
Pour supprimer une cible en mode ligne de commande, vous pouvez lancer
$ emcli delete_target
-name=rac1
-type=oracle_database
Pour une liste complète des commandes disponibles en ligne de commande, regardez encore la doc... Je pense qu'il m'a fallu moins de temps pour écrire ce post qu'il ne m'en aurait fallu pour supprimer ces 42 cibles manuellement. Est-ce que ça vous donne des idées ?