Mettre en place une base de secours physique PRODDBDG (Standby ou DataGuard) pour la base de données PRODDB de production se trouvant sur le serveur PRODSERV1.
1-Généralités :
- Une base de données (appelée base source) dans laquelle la perte de modifications n’est pas acceptable peut être associée à une base de secours (standby). Ceci permet de maintenir la réplication d’une base source en temps réel.
- Pour maintenir la base standby synchronisée avec la base source, les transactions validées de cette dernière y sont copiées en temps réel et appliquées automatiquement. En cas de défaillance de la base source, la base standby peut en quelques minutes reprendre la fonction de la base source. Les pertes restent ainsi minimales. On perd, en général, les transactions en cours (non validées).
- Lorsque la base standby est ouverte, elle devient la base source. Pour pouvoir la réutiliser en mode standby, il faut la re-créer.
- Possibilité de consulter des données dans la base standby (mode read-only).
2- pré-requis
Data Guard impose les contraintes de configuration suivantes sur le logiciel Oracle Database :
- La même version d’Oracle Database Enterprise Edition pour la base de données principale et toutes les bases de votre configuration Data Guard.
- Attribution du rôle SYSDBA aux comptes Oracle utilisés pour gérer les instances de la base de données principale et des bases de données de secours. L’utilisateur SYS doit avoir le même mot de passe dans toutes les bases de données de la configuration.
- La base de données principale et la base de données de secours doivent avoir leur propre fichier de contrôle.
- La base de données principale doit être configurée en mode ARCHIVELOG.
- Avant de constituer les sauvegardes des fichiers de données destinées à créer la base de secours, activer le mode FORCE LOGGING pour :
- forcer l’écriture d’enregistrements de journalisation même quand l’option NOLOGGING a été précisée dans les instructions LDD.
- éviter toute écriture directe (non journalisée) dans la base de données principale qui ne pourrait pas être propagée à la base de données de secours.
3- Architecture :
[album id= »314547″]
Data Guard exploite des informations de journalisation qui existent déjà dans la base de données pour assurer la synchronisation des bases de données de secours avec la base de données principale.
Le fait d’utiliser l’architecture existante permet de réduire l’impact de Data Guard sur la base de données principale.
Pour réaliser l’automatisation nécessaire à la récupération après sinistre et au maintien d’une haute disponibilité, Data Guard fait appel à plusieurs processus.
Dans la base de données principale, les services de transfert de fichier de journalisation utilisent les processus suivants :
- LGWR – Le processus LGWR collecte les informations de journalisation des transactions et met à jour les fichiers de journalisation en ligne (online redo logs).
En mode asynchrone (retenu) :
il transfère directement les informations de journalisation mais n’attend pas de confirmation pour continuer. Le processus LGWR soumet la demande d’E/S réseau au processus LNSn (LGWR Network Server) correspondant à la destination.
- ARCn – Le processus d’archivage ARCn crée une copie locale des fichiers de journalisation en ligne, destinée à être utilisée pour récupérer la base de données principale. Il peut également transférer le flux d’informations de journalisation vers le processus de serveur de fichiers distants RFS tout en archivant simultanément le fichier de journalisation en ligne. Le processus ARCn est également chargé de détecter de manière proactive et de résoudre les décalages dans la base de secours.
- FAL – Le processus FAL (Fetch Archive Log – récupération de fichiers archivés) fournit un mécanisme client/serveur permettant de résoudre les décalages détectés dans la série de fichiers archivelogs qui sont générés sur la base de données principale et reçus sur la base de données de secours. Ce processus ne démarre qu’en cas de nécessité et s’arrête dès qu’il a terminé.
Remarque :
On configure une base de données principale pour qu’elle utilise un seul des deux processus ARCn et LGWR (retenue) pour transférer les informations de journalisation.
Dans le mode LGWR de transfert (retenu), l’attribut LGWR du paramètre LOG_ARCHIVE_DEST_2 indique que les informations de journalisation sont transmises à la destination en même temps qu’elles sont écrites dans le fichier de journalisation en ligne (online redo log). La fonction de service de transfert de fichier de journalisation est assurée par le processus en arrière-plan Log Writer (LGWR). Lorsque le processus LGWR transfère les informations de journalisation vers des destinations distantes, il établit une connexion réseau avec l’instance destinataire. Si une destination du processus LGWR échoue, elle se remet automatiquement à utiliser le processus d’archivage (ARC) jusqu’à la résolution de l’erreur.
Avec l’attribut LGWR, vous pouvez préciser les options supplémentaires suivantes :
- ASYNC[=blocks] : Indique que les E/S réseau doivent être traitées de manière asynchrone pour la destination considérée. Autrement dit, une fois l’opération d’E/S lancée, le processus LGWR n’attend pas son achèvement et ne vérifie pas qu’elle s’est bien déroulée pour traiter la demande suivante. L’attribut ASYNC permet de tenir à jour des environnements de secours avec un impact minime ou nul sur les performances de la base principale. Le nombre de blocs (facultatif) détermine la taille de la mémoire tampon réseau SGA à utiliser. En règle générale, ce nombre de blocs est d’autant plus grand que la connexion réseau est lente. La valeur par défaut est 2048.
- NOAFFIRM : Indique que toutes les opérations d’E/S disque sur les informations de journalisation doivent être effectuées de manière asynchrone et que le processus Log Writer (LGWR) n’attend donc pas la fin d’une opération d’E/S disque pour continuer. Il s’agit de l’attribut par défaut.
3.1 Flux sur la base de données de secours
Dans la base de données de secours, les services de traitement de fichier de journalisation utilisent les processus suivants :
- RFS – Le processus de serveur de fichiers distants (RFS – Remote File Server) reçoit les informations de journalisation en provenance de la base de données principale. Il peut les écrire dans des fichiers de journalisation de secours ou directement dans des fichiers de journalisation archivés.
- ARCn – Le processus d’archivage ARCn archive les fichiers de journalisation de la base de données secours.
- MRP – Le processus MRP (Managed Recovery Process) applique les informations des fichiers de journalisation archivés à la base de données de secours physique. Si on lance la récupération avec l’instruction SQL :
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT ;
le processus en arrière-plan MRP démarre.
3.2 . Modes de protection des données
Oracle Data Guard prend en charge trois modes de protection des données :
- protection maximale,
- disponibilité maximale
- performances maximales
Pour permettre d’établir un compromis entre les besoins en ce qui concerne la disponibilité des données et les performances du système.
Dans certains cas, la perte de données doit être évitée à tout prix. Dans d’autres, c’est la disponibilité de la base qui prime sur le risque de perdre des données. Enfin, certaines applications nécessitent des performances maximales et peuvent tolérer des pertes de données.
Performances maximales (retenu)
Ce mode de protection (mode par défaut) assure le niveau de protection des données le plus élevé et qui ne compromet pas les performances de la base principale. Pour ce faire, il permet la validation (commit) d’une transaction dès que les données de journalisation nécessaires à la récupération de cette transaction sont écrites dans le fichier de journalisation en ligne (online redo log) local. Le flux des données de journalisation de la base principale est également écrit dans au moins une base de secours, mais de façon asynchrone par rapport à la validation des transactions qui créent les données de journalisation.
Lorsque les liaisons réseau utilisées présentent une bande passante suffisante, le mode de performances maximales fournit un niveau de protection des données proche de celui du mode de disponibilité maximale, mais avec un impact minime sur les performances de la base principale.
Le mode de performances maximales admet les attributs LGWR et ASYNC ou l’attribut ARCH pour le paramètre LOG_ARCHIVE_DEST_n de la base de secours destinataire. Les attributs LGWR et ASYNC permettent de réduire la quantité de données non reçues par la destination de secours en cas de panne de la base principale.
3.3 .Différer l’application des informations de journalisation :
Nous pouvons différer l’application des modifications aux bases de données de secours pour protéger ces dernières contre les erreurs humaines et la corruption des données. On évite ainsi d’appliquer des données corrompues ou erronées aux bases de secours. Le processus d’application valide à nouveau les enregistrements de journalisation pour empêcher l’application de données corrompues.
Par exemple, si une table d’importance critique est supprimée accidentellement dans la base principale, nous pouvons empêcher la répercussion de cette action dans la base de secours en différant l’application de la modification.
L’attribut DELAY=minutes du paramètre d’initialisation LOG_ARCHIVE_DEST_n sur la base principale et sur la base de secours physique permet de différer l’application des archivelogs à la base de secours.
Remarque :
Si on ne précise aucune valeur pour « minutes », le délai par défaut est de 30 minutes.
4- Création de la base de secours :
Les serveurs de production (PRODSERV1) et de secours (STDBYSERV1) ont la même architecture physique et logique (disques, partitions).
Commencez par la création des répertoires utilisés par Oracle :
ü D:\oracle\diag\rdbms\PRODDB\PRODDB\trace.
E:\ORADATA\PRODDB
E:\ORADATA\PRODDB\archivelog
Copier le fichier de paramètres d’initialisation spfilePRODDB.ora de la base PRODDB de production sous le nom %ORACLE_HOME%\database\spfilePRODDBDG.ora sur le serveur de secours.
4.1. Créer le service de l’instance standby sur le serveur STDBYSERV1
oradim –new –sid PRODDBDG -intpwd admin -startmode manual
4.2. Configurer le fichier de paramètres d’initialisation de la base de production
Ci-dessous, le contenu du fichier de paramètres d’initialisation spfilePRODDB.ora. Certains paramètres spéciaux doivent être configurés :
*.audit_file_dest=’D:\oracle\admin\PRODDB\adump’
*.compatible=’11.2.0.0.0′
*.control_files=’E:\oradata\PRODDB\control01.ctl’,’E:\oradata\PRODDB\control02.ctl’
*.db_block_size=8192
*.db_domain= »
*.db_name=’PRODDB’
*.db_unique_name=’PRODDB’
*.diagnostic_dest=’D:\oracle’
*.dispatchers='(PROTOCOL=TCP) (SERVICE=PRODDBXDB)’
*.fal_client='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=PRODSERV1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=PRODDB)(INSTANCE_NAME=PRODDB)(SERVER=dedicated)))’
*.fal_server='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=STDBYSERV1)(PORT=1522)))(CONNECT_DATA=(SERVICE_NAME=PRODDBdg)(SERVER=dedicated)))’
*.global_names=true
*.local_listener=’LISTENER_PRODDB’
*.log_archive_dest_1=’LOCATION=E:\oradata\PRODDB\archivelog’
*.log_archive_dest_2=’service= »(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=STDBYSERV1)(PORT=1522)))(CONNECT_DATA=(SERVICE_NAME=PRODDBDG)(INSTANCE_NAME=PRODDBDG)(SERVER=dedicated))) »‘,’ LGWR ASYNC NOAFFIRM delay=0 OPTIONAL reopen=300 db_unique_name= »PRODDBdg »‘
*.log_archive_format=’ARC%S_%R.%T’
*.memory_target=16G
*.nls_language=’FRENCH’
*.nls_territory=’FRANCE’
*.open_cursors=300
*.processes=800
*.remote_login_passwordfile=’EXCLUSIVE’
*.standby_file_management=’auto’
*.undo_tablespace=’UNDOTBS1′
Le paramètre d’initialisation LOG_ARCHIVE_DEST_STATE_n indique l’état de la destination définie par le paramètre d’initialisation LOG_ARCHIVE_DEST_n.
Par exemple, le paramètre LOG_ARCHIVE_DEST_STATE_1 indique l’état de la destination LOG_ARCHIVE_DEST_1
. Les valeurs suivantes utilisées dans l’installation :
- ENABLE – Indique qu’une destination d’archivage des fichiers de journalisation valide peut être utilisée pour une opération d’archivage ultérieure. Il s’agit de l’attribut par défaut.
- DEFER – Indique que les informations et les attributs de destination valides sont conservés, mais que la destination est exclue des opérations d’archivage tant qu’elle n’a pas été réactivée.
En rouge les valeurs à bien configurer sinon par d’envois des archivelog sur la base de secoue
4.3 Activer le mode FORCE LOGGING dans la base de production
ALTER DATABASE FORCE LOGGING ;
Il détermine si le serveur de base de données Oracle enregistre toutes les modifications effectuées dans la base de données, à l’exception de celles apportées aux tablespaces temporaires et aux segments temporaires.
4.4 Configurer le fichier de paramètres d’initialisation de la base de secours:
*.aq_tm_processes=1
*.compatible=’11.2.0.0.0′
*.control_files=’E:\oradata\PRODDB\control01.ctl’,’E:\oradata\PRODDB\control02.ctl’
*.db_block_size=8192
*.db_domain= »
*.db_name=’PRODDB’
*.db_unique_name=’PRODDBDG’
*.diagnostic_dest=’d:\oracle’
*.dispatchers='(PROTOCOL=TCP) (SERVICE=PRODDBXDB)’
*.fal_client='(description=(address_list=(address=(protocol=tcp)(host=STDBYSERV1)(port=1522)))(connect_data=(sid=PRODDBDG)(server=dedicated)))’
*.fal_server='(description=(address_list=(address=(protocol=tcp)(host=PRODSERV1)(port=1521)))(connect_data=(sid=PRODDB)(server=dedicated)))’
*.fast_start_mttr_target=300
*.global_names=TRUE
*.instance_name=’PRODDBDG’
*.local_listener=’LISTENER_PRODDBDG’
*.log_archive_dest_1=’LOCATION=E:\oradata\PRODDB\archivelog MANDATORY REOPEN=300′
*.log_archive_format=’ARC%S_%R.%T’
*.memory_target=16G
*.nls_language=’FRENCH’
*.nls_territory=’FRANCE’
*.open_cursors=300
*.processes=800
*.remote_login_passwordfile=’EXCLUSIVE’
*.standby_file_management=’auto’
*.undo_tablespace=’UNDOTBS1′
4.4 Configurer les fichiers listener.ora et tnsnames.ora sur le serveur de production :
Le contenu du fichier %ORACLE_HOME%\network\admin\listener.ora :
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = CLRExtProc)
(ORACLE_HOME = D:\oracle\product\11.2.0\dbhome_1)
(PROGRAM = extproc)
(ENVS = « EXTPROC_DLLS=ONLY:D:\oracle\product\11.2.0\dbhome_1\bin\oraclr11.dll »)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = PRODSERV1)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC41521))
)
)
ADR_BASE_LISTENER = D:\oracle
Le fichier %ORACLE_HOME%\network\admin tnsnames.ora :
LISTENER_PRODDB =
(ADDRESS = (PROTOCOL = TCP)(HOST = PRODSERV1)(PORT = 1521))
ORACLR_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC41521))
)
(CONNECT_DATA =
(SID = CLRExtProc)
(PRESENTATION = RO)
)
)
PRODDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = PRODSERV1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = PRODDB)
)
)
PRODDBDG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = STDBYSERV1)(PORT = 1522))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = PRODDBDG)
)
)
4.5 Configurer les fichiers listener.ora et tnsnames.ora sur le serveur de secours
Le nouveau listener portant le nom PRODDBDG est crée pour la base de secours ; il utilise le port 1522 :
Listener
SID_LIST_LISTENER_STDBYSERV1 =
(SID_LIST =
(SID_DESC =
(SID_NAME = CLRExtProc)
(ORACLE_HOME = D:\oracle\product\11.2.0\dbhome_1)
(PROGRAM = extproc)
(ENVS = « EXTPROC_DLLS=ONLY:D:\oracle\product\11.2.0\dbhome_1\bin\oraclr11.dll »)
)
)
LISTENER_PRODDBDG =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = STDBYSERV1)(PORT = 1522))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC41522))
)
)
tnsnames.ora
PRODDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = PRODSERV1)(PORT = 41521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = PRODDB)
)
)
PRODDBDG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = STDBYSERV1)(PORT = 1522))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = PRODDBDG)
)
)
LISTENER_PRODDBDG =
(ADDRESS = (PROTOCOL = TCP)(HOST = STDBYSERV1)(PORT = 1522))
RMANCATALOG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = RMANSERVEUR)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RMANCATALOG)
)
)
Pour la duplication de la prod vers la standby , on utilisera le catalogue RMAN
4.6 Création de la base de secours sur le serveur STDBYSERV1
Etapes :
1) Copier le fichier de mots de passe externe de la base de production:
%ORACLE_HOME%\database\PWDPRODDB.ORA (PRODSERV1) sous le nom
%ORACLE_HOME%\database\PWDPRODDBDG.ORA (STDBYSERV1)
Pour que le transfert des données de journalisation réussisse, les bases de données d’une configuration Data Guard doivent utiliser
le même fichier de mots de passe externe et le même mot de passe de l’utilisateur SYS.
2) Depuis le serveur de secours STDBYSERV1, effectuer la sauvegarde à chaud de la base PRODDB de production:
rman target sys/sysadmin@PRODDB
run {
sql ‘alter system archive log current’;
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
backup as compressed backupset tag ‘bd_tot_dg’ format ‘E:\BACKUP\DF_%s.BAK’ database;
backup current controlfile for standby tag ‘ctrl_dg’ format ‘E:\BACKUP\CTRL_%s.BAK’ current controlfile;
sql ‘alter system switch logfile’;
backup as compressed backupset tag ‘archive_dg’ format ‘E:\BACKUP\ARC_%s.BAK’ archivelog from time ‘sysdate-3’ not backed up 1 times;
release channel c1;
release channel c2;
release channel c3;
release channel c4;
}
La sauvegarde a été générée dans E:\BACKUP sur PRODSERV1. Il faut les copier sur STDBYSERV1.
3) Démarrer l’instance standby
Set ORACLE_SID=PRODDBDG
net start oracleservicePRODDBDG
sqlplus sys/sysadmin as sysdba
STARTUP NOMOUNT
4) duplication de la base de prod depuis le serveur de secour
rman target sys/sysadmin@PRODDB auxiliary sys/sysadmin
rman>
run
{
duplicate target database for standby
nofilenamecheck dorecover;
}
5) Copie du fichier tempfile de la production vers la standby
Copier E:\ORADATA\PRODDB\TEMP01.DBF (PRODSERV1) dans
E:\ORADATA\PRODDB (STDBYSERV1)
6) Créer les standby redologs dans la base de secours
Les fichiers de journalisation de secours doivent être au moins aussi nombreux que les fichiers de journalisation de la base de données principale. Il est recommandé d’avoir un groupe de fichiers de journalisation de secours supplémentaire par rapport au nombre de groupes de fichiers de journalisation en ligne (online redo logs) de la base de données principale.
Les fichiers de journalisation de secours doivent être de taille égale ou supérieure à celle des fichiers de journalisation en ligne de la base principale.
Le processus RFS écrit dans un archivelog dans les cas suivants :
- Il n’existe aucun fichier de journalisation de secours
- Il n’existe pas de fichier de journalisation de secours présentant la même taille que le fichier de journalisation en ligne à traiter.
- Tous les fichiers de journalisation de secours de taille correcte n’ont pas encore été archivés.
Set ORACLE_SID=PRODDBDG
sqlplus sys/sysadmin as sysdba
ALTER DATABASE ADD STANDBY LOGFILE ‘E:\ORADATA\PRODDB\redostd10.dbf’ size 200M;
ALTER DATABASE ADD STANDBY LOGFILE ‘E:\ORADATA\PRODDB\redostd11.dbf’ size 200M;
ALTER DATABASE ADD STANDBY LOGFILE ‘E:\ORADATA\PRODDB\redostd12.dbf’ size 200M;
7) La mise en mode Redo Apply de la base de secours :
Set ORACLE_SID=PRODDBDG
sqlplus sys/admin as sysdba
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
5 -Démarrage de la base de secours :
Le service Oracle « OracleServicePRODDBDG» de la base de secours sur STDBYSERV1 doit être démarré. Ensuite, ouvrez une fenêtre Dos et lancez l’utilitaire sqlplus /nolog , et tapez :
connect sys/admin as sysdba
STARTUP NOMOUNT
ALTER DATABASE MOUNTSTANDBY DATABASE;
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
On peut faire un petit script de démarrage
La base standby PRODDBDG ne peut pas être démarrée avec la commande « startup open »,
car elle doit être montée et en mode recover,
par conséquent son service OracleServicePRODDBDG ne démarre pas automatiquement.
Le script demarre_std.sql doit être utilisé pour démarrer la base de secours si besoin est
shutdown abort
startup nomount
alter database mount standby database;
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
exit
5.1 Ouverture de la base de secours en lecture seule (« READ ONLY »)
Il est possible d’ouvrir une base de secours en lecture seule (read-only) .
Avantage :
- Permet de s’assurer que la base de secours fonctionne correctement puisqu’elle peut être ouverte et répondre aux demandes
- Elle peut être utilisée à des fins de reporting et ainsi décharger la base source.
Nota :
Aucune donnée ne peut être modifiée dans une base qui opère en mode read-only. Les transactions validées seront transférées et mises en attente d’application sur le serveur de secours. La base de secours ne doit pas rester ouverte trop longtemps dans ce mode. Le délai d’activation de cette base en cas de défaillance de la base source risquerait sinon d’être considérablement allongé.
Pour placer la base de secours en lecture seule, taper :
ALTER DATABASE OPEN READ ONLY;
Pour remettre la base de secours dans le mode de récupération et appliquer automatiquement les transactions validées transmises entre temps par la base de production,
taper
SHUTDOWN IMMEDIATE
STARTUP NOMOUNT
ALTER DATABASE MOUNTSTANDBY DATABASE;
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
6 Activation de la base de secours :
La base de secours peut être activée pour remplacer la base source défaillante. A la demande du client, l’activation sera toujours manuelle selon la procédure décrite.
Pour activer la base de secours, taper :
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH WAIT;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN IMMEDIATE
STARTUP
Nota :
Pour des raisons de sécurité la base de secours activée doit utiliser un listener qui utilise un port spécifique (dans notre cas, le port 1522).
Le listener utilisé par défaut doit être arrêté. L’ensemble de connexions applicatives doivent être redirigé sur le serveur de secours STDBYSERV1 .
Au moment de la création de la base de secours, seuls les datafiles des tablespaces de type « PERMANENT » et « UNDO » sont copiés. Cela veut dire que la base de secours ne contient pas de TEMPORARY tablespace après son activation (ou plus précisément un temporary datafile).
Pour cette raison il faut l’ajouter :
ALTER TABLESPACE temp ADD
TEMPFILE ‘E:\ORADATA\PRODDB\TEMP01.dbf’ REUSE ;
6.1 Configuration client en cas d’échec :
Pour assurer une connexion, en cas de l’échec du site primaire, une configuration spécifique doit être mise en œuvre.
Il est important de positionner du côté du client le paramètre
SQLNET.OUTBOUND_CONNECT_TIMEOUT = 3
dans le fichier %ORACLE_HOME%\network\admin\sqlnet.ora
pour s’assurer que les connexions échouées n’attendront pas le temps mort TCP (timeout), mais passeront immédiatement au serveur suivant de la configuration si le site primaire est indisponible.
Création du service PRD :
Sqlplus sys/sysadmin@PRODDB as sysdba
begin
DBMS_SERVICE.CREATE_SERVICE (
service_name => ‘PRD‘,
network_name => ‘PRD’,
failover_method => ‘BASIC’,
failover_type => ‘SELECT’,
failover_retries => 180,
failover_delay => 1);
end;
/
Création du trigger système :
CREATE OR REPLACE TRIGGER gestion_dgservice
after startup on database
DECLARE
role VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
IF role = ‘PRIMARY’ THEN
DBMS_SERVICE.START_SERVICE(‘PRD’);
END IF;
END;
/
Dans le fichier tnsnames.ora du côté du client ajoutez le service :
PRD =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = PRODSERV1 (PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = STDBYSERV1)(PORT = 1522))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVICE_NAME = PRD)
)
)
7- COMMANDE DE MAINTENANCE DATAGUARD :
Une fois la configuration terminée , il faut écrire une script qui permet de vérifier si le serveur de secours n’a pas trop d’écart avec la production, ce script check tout les 15 minutes et envois un mail
si le gap est important entre les deux serveurs .
select al.thrd « Thread », almax « Last Seq Received », lhmax « Last Seq Applied »
from (select thread# thrd, max(sequence#) almax
from v$archived_log
where resetlogs_change#=(select resetlogs_change# from v$database)
group by thread#) al,
(select thread# thrd, max(sequence#) lhmax
from v$log_history
where first_time=(select max(first_time) from v$log_history)
group by thread#) lh
where al.thrd = lh.thrd;
Thread Last Seq Received Last Seq Applied
———- —————– —————-
1 2055 2055
–Vérifier les archivelogs qui manquent sur la standby
select * from v$archive_gap;
select process, status, thread#, sequence# from v$managed_standby;
select max(sequence#) from v$log_history where trunc(first_time) > sysdate-1; –on primery and standby
–verifier sur la base principale le dernier fichier appliquer:
–verifier les deux bases
sqlplus /nolog @\verif_gap.sql > verif.log
set instance SOURCE — tns name
connect sys/sysadmin as sysdba
set head off
spool max_seq_source.lst
select max(sequence#) from v$log_history;
spool off
disconnect
set instance STDBY — tns name
connect sys/sysadmin as sysdba
set head off
spool max_seq_stdby.lst
select max(sequence#) from v$log_history;
spool off
exit
8 – Restauration base de secours:
si le gap est tres important entrant la prod et la base de secours le mise est de faire une restauration full de la base que de rejour les archives logs
ci-dessous quelque étapes :
Dans l’exemple ci-dessous le gap entre la base de secours est très important
sbty
——–
SQL> SELECT to_char(CURRENT_SCN) FROM V$DATABASE;
TO_CHAR(CURRENT_SCN)
—————————————-
87457395714
SQL>
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
creation du fichier de parametre :
startup nomount
create pfile from spfile;
2) backup controlfile
backup current controlfile for standby tag ‘ctrl_dg’ format ‘F:\BACKUP\CTRL_%s.BAK’ current controlfile;
2) backup sur la primaire RMAN
3) restoration du controlfile
restore standby controlfile from ‘F:\backup\CTRL_%s.BAK_STDY.BAK’;
3) register avec catalogue sur la standby ‘
CATALOG START WITH ‘\\share_rman_backup\’;
4) restoration data
restore database
5) restoration du TMFILE
Copier \\share_rman_backup\TEMP…..DBF dans F:\ORADATA\PRODDB
6) creation des fichiers redo apres verification
— mdc verifier la taille des redo add (nbr redo + 1)
————————————————————————
ALTER DATABASE ADD STANDBY LOGFILE group 10 ‘F:\oradata\PRODDB\STDBYLOG\SITR_REDLOG10.dbf’ size 800M reuse ;
ALTER DATABASE ADD STANDBY LOGFILE group 11 (‘F:\ORADATA\PRODDB\STDBYLOG\SITR_REDLOG11.dbf’) size 800M reuse ;
ALTER DATABASE ADD STANDBY LOGFILE group 12 (‘F:\ORADATA\PRODDB\STDBYLOG\SITR_REDLOG12.dbf’) size 800M reuse ;
ALTER DATABASE ADD STANDBY LOGFILE group 13 (‘F:\ORADATA\PRODDB\STDBYLOG\SITR_REDLOG13.dbf’) size 800M reuse ;
6) recover
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
6.1) activation des envoies
–Primary
–Primary
ALTER SYSTEM SET log_archive_state_2=enable;
ALTER SYSTEM SET standby_file_management=’auto’;
ALTER SYSTEM SET log_archive_dest_2=’service= »(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=STDBYSERV1)(PORT=1522)))(CONNECT_DATA=(SERVICE_NAME=PRODDBDG)(INSTANCE_NAME=PRODDBDG)(SERVER=dedicated))) »‘,’ LGWR ASYNC NOAFFIRM delay=0 OPTIONAL reopen=300 COMPRESSION=ENABLE db_unique_name= »PRODDBDG »‘ SCOPE=spfile;
7) si gap
prendre le numero de sequence actuel de la production
et faire creer un catalogue temporaire avec le chemin des archives
catalog start with »\\share_rman_backup\\SAUVEGARDES\DATABASE\’;
run {
restore archivelog from sequence 2088 until sequence 2188;
}