Oracle DB 9i-10g - Ora-Linux

Calendrier

Novembre 2008

Articles récents

liste complète

Recherche

Liens

W3C

précédent 1 2

Samedi 18 novembre 2006

StandBy Database 9i Release 2 sous Windows

L'autre jour, on m'a demandé de configurer une StandBy Database, pour une base de données 9i Release 2 sous Windows ...
Je vous livre ce que j'ai fait, brut de fonderie... Il s'agit ici d'une 'Physical Standby Database' qui, contrairement à une 'Logical Standby Database', n'est pas disponible, même pour le seul requêtage, puisqu'elle n'est pas ouverte, mais seulement montée dans un mode particulier de recouvrement.

Configuration des serveurs

Prim : primary database
    SERVPRIM - 192.168.73.142
    Microsoft Windows 2003 Server
    Version RDBMS = 9.2.0.5.0
    ORACLE_HOME = E:\oracle\ora92
    ORACLE_SID = PRIM
    SPFILE = F:\Production\Database\scripts\SPFILEPRIM.ora

SB : standby database
    SERVSTAND - 192.168.73.102
    Microsoft Windows Server 2003
    Version RDBMS : 9.2.0.5.0
    ORACLE_HOME = E:\oracle\ora92
    ORACLE_SID = STANDBY

1/ Passage de Prim en mode ARCHIVELOG

On travaille dans une fenêtre DOS, après avoir positionner correctement la variable d'environnement ORACLE_SID.

$ set oracle_sid=prim

    $ sqlplus sys/change_on_install as sysdba
    > archive log list;
    mode Database log              mode No Archive
    Archivage automatique             DÚsactivÚ
    Destination de l'archive             e:\oracle\ora92\RDBMS
    SÚquence de journal en ligne la plus ancienne     45
    SÚquence de journal courante            48

    > create pfile='F:\Production\Database\Scripts\initPRIM.ora' from
    spfile='F:\Production\Database\Scripts\SPFILEPRIM.ORA';

    > shutdown immediate;

- modification du PFILE ( F:\Production\Database\scripts\initPRIM.ora ), ajout de :
    # Archivelog
    LOG_ARCHIVE_DEST='F:\Production\Database\archive'
    LOG_ARCHIVE_START=true
    log_archive_format=%t%s%r.arc

- redémarrage et passage en mode archivelog :
    $ sqlplus sys/change_on_install as sysdba
    > startup mount pfile=F:\Production\Database\scripts\initPRIM.ora
    > alter database archivelog;
    > alter database open;

    > create spfile='F:\Production\Database\Scripts\SPFILEPRIM.ORA' from
    pfile='F:\Production\Database\scripts\initPRIM.ora';

2/ Préparation de la base primaire

. création du fichier de contrôle :
    $ sqlplus sys/change_on_install as sysdba
    > alter database create standby controlfile as 'F:\Production\Database\Systeme\PRIM_standby.ctl';

. arrêt propre de la base :
    > shutdown immediate;

. sauvegarde de la base et recopie sur le serveur de secours (ici, l'ensemble des fichiers de la base de données sont éclatés sur E: et F:) :

    - copie de toute l'arborescence SERVPRIM:F:\Production sur SERVSTAND:F:\Production
    - copie de SERVPRIM:E:\Production\LVA sur SERVSTAND:E:\Production\LVA

. modification du PFILE de Prim, ajout des lignes suivantes :

    # Config. pour StandBy
    log_archive_dest_1='LOCATION=F:\Production\Database\archive MANDATORY REOPEN=5'
    log_archive_dest_2='SERVICE=STANDBY LGWR ASYNC REOPEN=10'
    log_archive_dest_state_1=ENABLE
    log_archive_dest_state_2=ENABLE
    standby_file_management='AUTO'

. modification du fichier TNS E:\oracle\ora92\network\admin\tnsnames.ora, ajout de :

    STANDBY =
    (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCP)(HOST = SERVSTAND)(PORT = 1521))
        )
        (CONNECT_DATA =
          (SERVICE_NAME = standby)
        )
    )

3/ Préparation de la StandBy

. rappel : à ce stade, tous les fichiers de la base Prim ont été recopiés sur le serveur SB, exactement au même endroit, et un noyau Oracle identique correctement installé.

. renommer le fichier de contrôle StandBy dans F:\Production\Database\Systeme :
    - sauvegarde et renommage des 2 originaux : CTRL1PRIM.ORA et CTRL2PRIM.ORA
    $ cp PRIM_standby.ctl CTRL1PRIM.ORA
    $ cp PRIM_standby.ctl CTRL2PRIM.ORA

. modification du PFILE :

    - on le renomme F:\Production\Database\scripts\initPRIM.ora en initstandby.ora

    control_files = (F:\Production\Database\systeme\ctrl1PRIM.ora, F:\Production\Database\systeme\ctrl2PRIM.ora)
    db_name            = PRIM
    instance_name      = STANDBY
    service_names      = STANDBY
    undo_management=AUTO
    undo_retention=10800
    undo_tablespace=UNDOTBS1
    remote_login_passwordfile = SHARED
    background_dump_dest      = F:\Production\Database\dump
    user_dump_dest            = F:\Production\Database\dump
    max_dump_file_size        = 10240
    STATISTICS_LEVEL      = BASIC
    timed_statistics      = false
    sql_trace             = false
    db_files = 120
    db_file_multiblock_read_count = 16
    db_block_size = 8192
    db_cache_size=24M
    shared_pool_size = 56000000
    processes = 400
    dml_locks = 500
    log_buffer = 262144
    open_cursors                = 300
    cursor_space_for_time       = true
    compatible                  = 9.2.0.0.0
    pga_aggregate_target        = 25165824
    java_pool_size              = 0
    LOG_ARCHIVE_DEST='F:\Production\Database\archive'
    LOG_ARCHIVE_START=true
    log_archive_format='log%s_%t.arc'
    # StandBy
    log_archive_dest_1='LOCATION=F:\Production\Database\archive'
    log_archive_dest_state_1=ENABLE
    fal_client='STANDBY'
    fal_server='PRIM'
    standby_file_management='AUTO'
    standby_archive_dest='F:\Production\Database\archive'

. création du service :
"e:\oracle\ora92\bin\oradim.exe" -new -sid standby -startmode manual -pfile "F:\Production\Database\scripts\initstandby.ora"

. création du fichier ORAPWD
    $ cd $ORACLE_HOME/database
    $ set oracle_sid=standby
    $ orapwd file=PWDstandby.ORA password=change_on_install

. configuration du listener de la StandBy via 'Net Configuration Assistant'

. démarrage de Prim
    > startup pfile=F:\Production\Database\scripts\initPRIM.ora

. démarrage de SB

    > STARTUP NOMOUNT PFILE=F:\Production\Database\scripts\initstandby.ora
    > ALTER DATABASE MOUNT STANDBY DATABASE;
    > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

. création du tablespace temporaire TMP (pour les opérations de tri lors d'un éventuel passage en READ ONLY)

    - arrêt du mode recover et passage en read-only :
    > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    > ALTER DATABASE OPEN READ ONLY;
    > alter tablespace tmp add tempfile 'F:\PRODUCTION\DATABASE\SYSTEME\TMP1PRIM.DBF' size 268435456 reuse;

    - on repasse en mode recover :
    > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

. création des standby redologs (permet l'enregistrment de chaque entrée des Redologs de la base Primaire sur la Standby, et donc réduit encore plus les probabilités de perte de données).
On a sur cette base 4 groupes (1 à 4) de 2 membres, il faut donc créer 4 nouveaux groupes (5 à 8) de 2 membres de 10Mo chacun ...

    - arrêt du mode recover
    > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

    - création des standby redologs :
    > alter database add standby logfile group 5 ('F:\PRODUCTION\DATABASE\LOG1\LOG15STANDBY.ORA',
        'E:\PRODUCTION\DATABASE\LOG2\LOG25STANDBY.ORA') size 10M;
    > alter database add standby logfile group 6 ('F:\PRODUCTION\DATABASE\LOG1\LOG16STANDBY.ORA',
        'E:\PRODUCTION\DATABASE\LOG2\LOG26STANDBY.ORA') size 10M;
    > alter database add standby logfile group 7 ('F:\PRODUCTION\DATABASE\LOG1\LOG17STANDBY.ORA',
        'E:\PRODUCTION\DATABASE\LOG2\LOG27STANDBY.ORA') size 10M;
    > alter database add standby logfile group 8 ('F:\PRODUCTION\DATABASE\LOG1\LOG18STANDBY.ORA',
        'E:\PRODUCTION\DATABASE\LOG2\LOG28STANDBY.ORA') size 10M;

    - on repasse en mode recover :
    > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

A ce niveau, la standby database est entièrement opérationnelle. On verra plus tard comment on l'exploite ...

par Ora-Linux publié dans : Oracle DB 9i-10g
ajouter un commentaire commentaires (0) recommander

Mardi 14 novembre 2006

Tracer une autre session !

A l'aide du package DBMS_SYSTEM, il est possible de générer des traces exploitables via TkProf de n'importe quelle session Oracle, et plus seulement de sa session courante...

1/ Repérer la session à tracer, et récupérer dans la vue système V$SESSION, les valeurs SID et SERIAL de cette session.

2/ Passer la session voulue (ex. SID=8 et SERIAL=121) en mode Trace :

  exec sys.dbms_system.set_sql_trace_in_session(8,121,TRUE);

3/ Faire ce qu'on a à faire (du Forms, du Sql, ce qu'on veut, quoi !)

4/ Arrêter le mode trace :

  exec sys.dbms_system.set_sql_trace_in_session(8,121,FALSE);

5/ Un p'tit coup de TkProf : on va sur $ORACLE_BASE/admin/<SID>/udump , on repère la trace générée,puis :

  tkprof <trace_générée> <output_file> explain=<username>/<password>

Zou.

par Ora-Linux publié dans : Oracle DB 9i-10g
ajouter un commentaire commentaires (1) recommander

Lundi 9 octobre 2006

Export / import de statistiques

On considère que l'on a une base de Production, avec plein de données dedans (...), et une base de développement, quasiment vide; ce qu'on souhaite, c'est faire en sorte que les plans d'exécutions de nos requêtes soient identiques. Comme on utilise l'optimiseur statistique (ben oui, on est en 10g, hé!), on va pouvoir gruger les traitements de la base de développements en leur faisant croire qu'il y a tout plein de données.

Exemple ici pour une table MATABLE, identique sur les 2 bases. On peut bien-sûr faire la même chose au niveau d'un schéma (dbms_stats.export_schema_stats).

Sur la base de données source
- calcul des stats
> analyze table matable compute statistics;

- création de la table de statistiques
> exec dbms_stats.create_stat_table('MONUSER','MATABLEDESTATS','USERS_TBS');

- sauvegarde des stats dans la table MATABLEDESTATS
> exec dbms_stats.EXPORT_TABLE_STATS(ownname=>'MONUSER',tabname=>'MATABLE',stattab=>'MATABLEDESTATS');

- export de la table de sauvegarde des statistiques
$ exp protect/protect file=exp_matabledestats log=exp_matabledestats tables=matabledestats

Sur la base de données cible
- import de la table de sauvegarde des statistiques
$ imp protect/protect file=exp_matabledestats log=exp_matabledestats tables=matabledestats

- restauration des statistiques
> exec dbms_stats.import_table_stats(ownname=>'MONUSER',tabname=>'MATABLE',stattab=>'MATABLEDESTATS');

Trucs & astuces
- suppression d'une table de statistiques
> exec dbms_stats.drop_stat_table('MONUSER','MATABLEDESTATS);

- suppression du contenu d'une table de statistiques
> exec dbms_stats.delete_table_stats(ownname=>'MONUSER',tabname=>'MATABLE',stattab=>'MATABLEDESTATS');

par Ora-Linux publié dans : Oracle DB 9i-10g
ajouter un commentaire commentaires (0) recommander

Lundi 9 octobre 2006

Déplacement de datafiles

2 méthodes : base arrêtée ou base démarrée, au choix ! On parle de déplacement de fichiers de données, mais les même procédures s'appliquent dans le cadre d'un renommage ...

1- Base arrêtée
- la base étant arrêtée, copier les datafiles avec la commande correspondant à l'OS
$ cp /u02/oradata/orcltst/users01.dbf /u03/oradata/orcltst/user01.dbf

- se connecter à la base en 'sys'
$sqlplus '/ as sysdba'

- démarrer la base sans l'ouvrir :
> startup mount;

- faire connaitre à la base le déplacement de fichier
> alter database rename file '/u02/oradata/orcltst/users01.dbf' to '/u03/oradata/orcltst/user01.dbf';

- ouvrir la base
> alter database open;

- vérifier la prise en compte des changements
> select name from dba_data_files;

- supprimer les fichiers avec la commande OS appropriée
$ rm -f /u02/oradata/orcltst/users01.dbf

2- Base ouverte
Afin de réaliser le déplacement de datafile 'base ouverte', le tablespace doit doit être passé en 'READ-ONLY', ce qui implique que les l'accès aux données de ce tablespace ne sera plus possible q'en 'SELECT' exclusivement. D'autre part, le temps de passage en mode 'READ-ONLY' peut être assez long, en fonction du volume, et éventuellement des transactions en cours.

- mettre le tablespace en READ-ONLY
> alter tablespace USERS read only;

- s'assurer que le tablespace est bien en READ-ONLY (!)
> select tablespace_name, status from dba_tablespaces where tablespace_name='USERS';

- copier les datafiles avec la commande correspondant à l'OS
$ cp /u02/oradata/orcltst/users01.dbf /u03/oradata/orcltst/user01.dbf

- mettre le tablespace offline
> alter tablespace users offline;
- faire connaitre à la base le déplacement de fichier
> alter database rename file '/u02/oradata/orcltst/users01.dbf' to '/u03/oradata/orcltst/user01.dbf';

- mettre le tablespace online
> alter tablespace users online;

- mettre le tablespace en mode READ-WRITE
> alter tablespace users read write;

- vérifier que tout est ok, en récupérant la trace dans $ORACLE_BASE/admin/bdump/XXXX.trc
> alter database backup controlfile to trace;

- supprimer les fichiers avec la commande OS appropriée
$ rm -f /u02/oradata/orcltst/users01.dbf

par Ora-Linux publié dans : Oracle DB 9i-10g
ajouter un commentaire commentaires (0) recommander

précédent 1 2

Blog : Sport sur over-blog.com - Contact - C.G.U. - Rémunération en droits d'auteur avec TF1 Network - Signaler un abus

Ora-Linux

Calendrier

Articles récents

Catégories

Recherche

Archives

Liens

W3C

StandBy Database 9i Release 2 sous Windows

Tracer une autre session !

Export / import de statistiques

Déplacement de datafiles