DATA PROTECTION and
DISASTER RECOVERY
DATA GUARD OVERVIEW
Oracle Data Guard maintains up to nine standby databases, each of which is a real-time copy of the production database, to protect against all threats—corruptions, human errors, and disasters. If a failure occurs on the production (primary) database, you can failover to one of the standby databases to become the new primary database. In addition, planned downtime for maintenance can be reduced because you can quickly and easily move (switch over) production processing from the current primary database to a standby database, and then back again.
Note: To protect against unlogged direct writes in the primary database that cannot be propagated to the standby database, turn on FORCE LOGGING at the primary database before taking datafile backups for standby creation. Keep the database (or at least important tablespaces) in FORCE LOGGING mode as long as the standby database is active.
Data Guard Configurations
A Data Guard configuration is a collection of loosely connected systems, consisting of a single primary database and up to nine standby databases that can include a mix of both physical and logical standby databases. The databases in a Data Guard configuration can be connected by a LAN in the same data center, or—for maximum disaster protection—geographically dispersed over a WAN and connected by Oracle Network Services.
A Data Guard configuration can be deployed for any database. This is possible because its use is transparent to applications; no application code changes are required to accommodate a standby database. Moreover, Data Guard lets you tune the configuration to balance data protection levels and application performance impact; you can configure the protection mode to maximize data protection, maximize availability, or maximize performance.
Data Guard Components
As application transactions make changes to the primary database, the changes are logged locally in redo logs, which are sent to the standby databases by log transport services and applied by log apply services.
For physical standby databases, the changes are applied to each physical standby database that is running in managed recovery mode.
For logical standby databases, the changes are applied using SQL regenerated from the archived redo logs.
DATA GUARD OVERVIEW
Physical Standby Databases
A physical standby database is physically identical to the primary database. While the primary database is open and active, a physical standby database is either performing recovery (by applying logs), or open for reporting access. A physical standby database can be queried read-only when not performing recovery while the production database continues to ship redo data to the physical standby site.
Physical standby on disk database structures must be identical to the primary database on a block-for-block basis, because a recovery operation applies changes block-for-block using the physical ROWID. The database schema, including indexes, must be the same, and the database cannot be opened (other than for read-only access). If opened, the physical standby database will have different ROWIDs, making continued recovery impossible.
Logical Standby Databases
A logical standby database takes standard Oracle archived redo logs, transforms the redo records they contain into SQL transactions, and then applies them to an open standby database. Although changes can be applied concurrently with end-user access, the tables being maintained through regenerated SQL transactions allow read-only access to users of the logical standby database. Because the database is open, it is physically different from the primary database. The database tables can have different indexes and physical characteristics from their primary database peers, but must maintain logical consistency from an application access perspective, to fulfill their role as a standby data source.
Data Guard Broker
Oracle Data Guard Broker automates complex creation and maintenance tasks and provides dramatically enhanced monitoring, alert, and control mechanisms. It uses background agent processes that are integrated with the Oracle database server and associated with each Data Guard site to provide a unified monitoring and management infrastructure for an entire Data Guard configuration. Two user interfaces are provided to interact with the Data Guard configuration, a command-line interface (DGMGRL) and a graphical user interface called Data Guard Manager.
Oracle Data Guard Manager, which is integrated with Oracle Enterprise Manager, provides wizards to help you easily create, manage, and monitor the configuration. This integration lets you take advantage of other Enterprise Manager features, such as to provide an event service for alerts, the discovery service for easier setup, and the job service to ease maintenance.
DATA GUARD BROKER
Nouveauté.
Outil de gestion d'un environnement data guard créer configurer administrer surveiller contrôler Quelle structure ?
Ÿ Interface Graphique data guard manager
Ÿ Interface "ligne de commande" command line interface (DGMGRL) Ÿ processus et fichiers de contrôle data guard monitor
Ÿ processus DMON alter system set
dg_broker_start
=true|falseŸ fichiers config alter system set
dg_broker_config_file1
|2
=filespecComment démarrer ? DGMGRL
dg_broker_star
t, anciennem
ent drs_sta rt
STANDBY 3 STANDBY 2 STANDBY 1 DATA GUARD BROKER : ANCRAGE
Network
BIEN VOIR :
Ÿ La modification dynamique des noms des fichiers de config doit se faire, DMON arrêté :
Ÿ alter system set dg_broker_start=false Ÿ pu i s
Ÿ alter system set dg_broker_config_file1=...
Ÿ pu i s
Ÿ alter system set dg_broker_start=true BIEN VOIR :
Ÿ DMON est un nouveau processus au même titre que LGWR ou DBWn : 1 DMON par INSTANCE et non pas par site physique
STANDBY 0
PRIMARY
dg_broker_config_file
2 DM O N
dg_broker_config_file 1
dg_broker_config_fil e 1|2 dg_broker_start=true|false dg_broker_config_file2
DMON
dg_broker_config_file1
dg_broker_config_file1|2 dg_broker_star t =true|fals e
dg_broker_config_file2 DMON
dg_broker_config_file1
dg_broker_config_file1|2 dg_broker_star t =true|fals e
dg_broker_config_file2 DMON
dg_broker_config_file1
dg_broker_config_file1|2 dg_broker_star t =true|fals e
dg_broker_config_file2
DMON dg_broker_config_file1
dg_broker_config_file1|2 dg_broker_star t =true|fals e
DATABASE SWITCHOVER
Nouveauté.
Une méthode pour basculer la standby en primary, en alternative de la méthode traditionnelle dite de "FAILOVER" qui impliquait une base sans secours, le temps des opérations de bascule.
Le switchover représente une solution élégante de secours contre les corruptions
corruptions physiques : ne sont pas répercutées dans les log stream, donc non véhiculées
corruptions logiques : ne sont pas appliquées sur la base standby si l'on a pris soin d'introduire un délai de recovery sur standby
(log_archive_dest_n='service=servnam delay=nbminutes) et que la corruption intervient dans ce délai.
Le switchover ECHANGE LES ROLES de la PRIMARY et de la STANDBY (l'une devient l'autre).
Le switchover nécessite que les deux bases (primary et standby) soient ramenées au même Point In Time (PIT).
Le switchover ne perd aucune donnée : il est une opération volontaire de bascule pour raisons de maintenance Database switchover
The new database switchover feature provides the database administrator (DBA) with the ability to switch the role of the primary database to one of the available standby databases. The chosen standby database becomes the primary database and the original primary database then becomes a standby database. There is no need to reinstantiate any of the databases in the switchover operation. There is no data divergence between the original and the new primary database after the successful completion of the database switchover.
A switchover operation is performed in two phases: first, the primary database role is switched to the standby role; then, a standby database is selected to assume the primary database role.
SWITCHOVER : VERIFICATIONS
dbs
prim<sid>.ora
prim<sid>.ora
$ORACLE_HOME
stdb<sid>.ora
stdb<sid>.ora
PRIMARY STANDBY
dbs
prim<sid>.ora
prim<sid>.ora
$ORACLE_HOME
stdb<sid>.ora
stdb<sid>.ora
CONTROL_FILES DB_FILE_NAME_CONVERT LOG_FILE_NAME_CONVERT
LOCK_NAME_SPACE
CONTROL_FILES DB_FILE_NAME_CONVERT LOG_FILE_NAME_CONVERT
LOCK_NAME_SPACE
SWITCHOVER : OPERATIONS SUR PRIMARY
PRIMARY
select SWITCHOVER_STATUS from V$DATABASE ;
SWITCHOVER_STATUS
--- -
TO STANDBYTO STANDBY indique que la base peut être candidate à une bascule "vers standby".
SESSI ON SHUTDOWN WITH
WITHOU T
W A I T NOW A I T switchover requiert 1 seule
session active. TUE OU PAS LES AUTRES SESSIONS
CONTROLE RETOURNE A LA FIN DU SWITCHOVER OU
IMMEDIATE M E N T
OPEN
MOUNT standby
NOMOUNT
ALTER DATABASE
MOUN T STAN D B Y DATABASE
V$DATABASE
Ÿswitchover_status Ÿ TO PRIMARY Ÿ SWITCHOVER PENDING Ÿ TO STANDBY
na m e
Départ
NOR MAL
NOMOU N T SHUTDOWN
STAR T U P
ALTER DATABASE
COMM I T TO
SWITCHOVER TO PHYSICAL STAN D B Y
SWITCHOVER : OPERATIONS SUR STANDBY
STANDBY
select SWITCHOVER_STATUS from V$DATABASE ;
SWITCHOVER_STATUS
--- -
SWITCHOVER PENDING
SWITCHOVER PENDING indique que la standby Ÿ était bien en recovery managed mode Ÿ que la primary a été basculée
Ÿ qu'elle est prête à prendre le rôle de primary
OPEN
MOUNT standby
select SWITCHOVER_STATUS from V$DATABASE ;
SWITCHOVER_STATUS
--- -
TO STANDBY
TO STANDBY indique que la base est primary et que son prochain état possible est STANDBY.
V$DATABASE
Ÿswitchover_status Ÿ TO PRIMARY Ÿ SWITCHOVER PENDING Ÿ TO STANDBY
na m e
V$DATABASE
Ÿswitchover_status Ÿ TO PRIMARY Ÿ SWITCHOVER PENDING Ÿ TO STANDBY
na m e SESSI ON SHUTDOWN
WITH WITHOU T
W A I T NOW A I T switchover requiert 1 seule
session active. TUE OU PAS LES AUTRES SESSIONS
CONTROLE RETOURNE A LA FIN DU SWITCHOVER OU IMMEDIATE M E N T
A cette occasion, création automatique des online redo logs.
STAR T U P SHUTDOWN
redo log redo log
redo log redo log
CREATE
Départ
ALTER DATABASE
COMM I T TO
SWITCHOVER TO PRIM A R Y
SWITCHOVER : OPERATIONS FINALES
NOUVELLE STANDBY
(a nc ie
nn e
pr im ar y)
ALTER DATABASE
RECOVER MAN AGED STANDBY DATABASE
DISCONNECT FROM SESSION
The MANAGED keyword in the ALTER DATABASE statement indicates that managed recovery, not manual recovery, will be performed. The DISCONNECT keyword in the ALTER DATABASE statement indicates that a separate background server process, or managed recovery process (MRP), should be created for the m a n a g e d r e c o v e r y . T h i s c a u s e s c o n t r o l t o b e immediately returned to the user and the managed recovery takes place in the background, and users can continue with other tasks. You can include optional FROM SESSION keywords, but these keywords can be omitted and the result is the same.
NOUVELLE PRIMARY
(a nc ie
nn e
st an db y)
ALTER SYSTEM
ARCHIVE LOG START
ALTER SYSTEM
SWITC H LOGFILE
groupe groupe
switch
ARCH
groupe
SCN k deb +1 SCN l deb
archiv e archiv e
SCN k deb SCN l deb
SCN k fin SCN l fin
+1
PHYSICAL STANDBY VS LOGICAL STANDBY
Nouveauté.
La standby database telle qu'en 8i est une PHYSICAL STANDBY DATABASE, au sens où elle est maintenue à jour sur la base d'une SIMILARITE BLOC TO BLOC basée sur les adresses physiques
en 9i, on a la possibilité d'avoir des LOGICAL STANDBY DATABASE dont la mise à jour est effectuée grace à des ordres SQL reconstruits à partir des enregs redo et appliqués sur la base distante. A ce titre, des recommandations existent pour les "supplemental data" nécessaires à la bonne reconstruction des ordres SQL sur la logical standby.
LOG TRANSPORT SERVICES
Nouveauté.
Jusqu'en 8i, la synchronisation de la primary database et de la standby database ne se faisait qu'à travers les échanges d'archives log.
en 8i, le transport de ces archives était assuré via le paramètre archive log_dest_n option service= qui permettait la constitution et le transfert d'archives sur la standby, grace à l'action conjointe des processus ARCn et RFSn.
En 9i, on permet EN PLUS, le transport des enregistrements redo unitaires, de façon synchrone ou asynchrone : On identifie une nouvelle couche appelée "TRANSPORT SERVICES"
On fixe ses exigences de transport à travers le seul paramètre archive_log_dest_n='service=srvname
synchro via archives arch
synchro via redo lgwr
émission synchrone avec écriture redo locale (synchro mode) sync
émission non synchrone (immediate mode) async
pour chacun confirmation d'écriture physique distante affirm
ou non confirmation noaffirm
Le LGWR devient donc acteur dans l'émission des enregs redo vers le distant, même si on fixe l'exigence dans archive_log_dest_n Dans le cas de l'asynchrone, un nouveau process apparaît : le shipping slave qui a comme fonction de gérer les émissions de redo vers le distant
Le log transport services permet de choisir parmi la plus large palette d'exigences entre performances de la standby
garantie de sauvegarde des modifications
lowest primary perf et highest save guaranty lgwr sync affirm
highest primary perf et lowest save guaranty lgwr async noaffirm
arch En 9i, on peut avoir 9 DESTINATIONS DISTANTES POSSIBLES (contre 4 en 8i)
Une option permet de demander que les émissions se fassent en parallèle vers toutes les destinations ENABLE PARALLEL
ou qu'elles se fassent en série avec atente d'éventuelles confirmations NOPARALLEL
Network connection
Les trois modes de véhiculage des modifications commitées : synchronous DCM, asynchronous DCM & batched DCM
full
Redo log buffer commit X
X X
commit
group e group e
switch
group e
SCN k deb +1 SCN l deb
archi v e archi v e
SCN k deb SCN l deb
SCN k fin SCN l fin +1
membremembre membremembre
redo log redo log
redo log redo log
redo log redo log
ARC3 ARC2 ARC1
RFS3 RFS2 RFS1
RECOVERY PASSIF sourd archives
standby_archive_dest=dest
/
Repert_ 2 1
Arc_10 0 1
Arc_10 0 6 Arc_10 0 2 Repert _ 1
Repert _ 2
Arc_10 0 5 Arc_10 0 3 Arc_10 0 4
archi v e
SAVOIR :
Ÿ sync peut être accompagné de la clause AFFIRM ou NOAFFIRM.
en fait, par défaut, l'aknowledge n'est émis qu'à bonne réception de l'archived log. pour confirmation liée à constituion complète sur distant, inscrire AFFIRM.
log_archive_deststate_n = ENABLED
'
log_archive_dest_n = ' service=stdby1 ARCH SYNC
Les trois modes de véhiculage des modifications commitées : synchronous DCM, asynchronous DCM & batched DCM
BIEN VOIR :
Ÿ Aucune donnée "primary" n'est comitée sans acquitement "write successfull on standby"
Ÿ Overheads entraînés par cet acquitement distant
Ÿ ZERO data loss : Toute database sinistrée est récupérable au moment strict du sinistre.
redo log redo log
redo log redo log
LGWR
Network connection
COMMIT ecriture OK ecriture OK
Process
serveur aknowledg e
log_archive_deststa t e _n = ENABLED
Redo log buffer
commit X
X X
commit
BIEN VOIR :
Ÿ C'est à travers le paramètre log_archive_dest_n que l'on préçise que c'est LGWR qui est utilisé pour le transport des redo logs vers les site standby distant.
Ÿ Le process serveur ne sera libéré que lorsque l'écriture distante sera effective.
'
log_archive_de st_n = ' service=stdby1 LGW R SYNC
SAVOIR :
Ÿ sync peut être accompagné de la clause PARALLEL ou NOPARALLEL: en cas de multiples destinations, NOPARALLEL attendra confirmation sur chaque destination avant de solliciter la suivante.
Ÿ sync peut être accompagné de la clause AFFIRM ou NOAFFIRM.
en fait, par défaut, l'aknowledge n'est émis qu'à bonne réception du
vecteur log. pour confirmation liée à écriture physique, inscrire AFFIRM.
Shipping Slave
Network connection : write request
Les trois modes de véhiculage des modifications commitées : synchronous DCM, asynchronous DCM & batched DCM
BIEN VOIR :
Ÿ les données redo sont transportées "dés que possible" vers le site standby distant Ÿ Pas d'overheads entraînés par l'écriture distante
Ÿ Toute database sinistrée n'est pas garantie récupérable A L'INSTANT MEME du SINISTRE.
redo log
redo log redo log
redo log
LGWR
COMMIT ecritu re OK
Process
serveur aknowledg e Redo log buffer
commit X
X X
commit
BIEN VOIR :
Ÿ C'est à travers le paramètre log_archive_dest_n que l'on préçise que c'est LGWR qui est utilisé pour le transport des redo logs vers les site standby distant.
Ÿ Le process serveur sera libéré dés que l'écriture locale sur redo log online sera effectuée, sans attendre confirmation écriture distante.
log_archive_deststa t e _n = ENABLED '
log_archive_de st_n = ' service=stdby1 LGW R ASYNC
RFS
SAVOIR :
Ÿ async peut être accompagné de la clause AFFIRM ou NOAFFIRM.
synchronous DCM, asynchronous DCM et degrés de fiabilité
' '
log_archive_de st_n = service=stdby1 LGW R
affirm
noaffirm
async sync
para llel noparallel
Perf prim db : hautes niveau sécu datas par
stdby : faible
Perf prim db : minimal niveau sécu datas par
stdby : maximal Perf prim db : maximal
niveau sécu datas par stdby : minimal
Perf prim db : faibles niveau sécu datas par
stdby : haut
The following example shows the AFFIRM attribute with the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_3=’SERVICE=stby1 LGWR SYNC AFFIRM’
LOG_ARCHIVE_DEST_STATE_3=ENABLE
CONFIGURER EN MODE "no-data-loss"
Nouveauté.
Deux notions existent :
Ÿ data divergence : due à travail en asynchronisme, ou pb standby / pb connexion avec standby ==>
temporairement, on peut avoir des données commitées sur la primary, qui ne sont pas sur la standby (par exemple, jusqu'à ce que FAL client de la standby demande des données manquantes).
Ÿ data loss : perte définitive de données à l'occasion d'un failover, alors qu'il existait une data divergence.
TRAVAILLER EN NO-DATA-LOSS implique l'utilisation d'un nouveau dispositif, le NO-DATA-LOSS FEATURE supporté à travers les commandes :
- SET STANDBY DATABASE {PROTECTED (to maximize protection) | UNPROTECTED (to maximize performance)}
– ADD [STANDBY] LOGFILE TO [THREAD integer] [GROUP integer] filespec – ADD [STANDBY] LOGFILE MEMBER ’filename’ [REUSE] TO GROUP integer contrôlé à travers la vue :
Ÿ V$ARCHIVE_DEST_STATUS(PROTECTION_MODE) maximum protected maximum availability resynchronization maximum performance unprotected
Oracle garantit qu'il n'existe aucune data divergence à aucun moment (potentiellement, il ne peut donc y avoir de data loss). Si la primary perd sa connexion avec ses standby, elle s'arrête. Une transaction ne peut pas commiter jusqu'à ce que toutes les données nécessaires au recover de cette transaction, n'aient été écrites AU MOINS SUR UNE PHYSICAL STANDBY configurée en SYNC log transport mode.
MODE NO-DATA-LOSS
ALTE R DATABAS E
SE T STANDBY
PROTECTI O N
TO MAXIMIZE AVAILABILITY
PERFORMANCE
Transaction ne commite QUE SI les données servant à assurer le RECOVER de cette transaction, ont été écrites sur au moins UNE PHYSICAL STANDBY configurée en SYNC.
Si PRIMARY incapable d'écrire sur au moins une (exemple, pb connexion), il y a SHUTDOWN de la PRIMARY
Transaction ne commite QUE SI les données servant à assurer le RECOVER de cette transaction, ont été écrites sur au moins UNE STANDBY (physical ou logical) configurée en SYNC.
Transaction commite sans avoir la certitude que les données servant à assurer le RECOVER de cette transaction, ont été écrites sur au moins UNE STANDBY.
BIEN VOIR:
Ÿ ON FIXE LES OPTIONS SYNC, AFFIRM et MANDATORY dans des paramètres ARCHIVE_LOG_DEST : ces paramètres ne concernent qu'une standby à la fois.
Ÿ TO MAXIMIZE PROTECTION ou TO MAXIMIZE AVAILABILITY fixent le comportement du primary vis à vis de l'ensemble des standby, dont certaines peuvent être en SYNC et d'autres non. Ces 2 modes s'intéressent aux standby en mode SYNC.
Ÿ La garantie provient du fait que la VIE de la primary dépend
Ÿ 1 de l'existence de standby MANDATORY/LGWR/SYNC/AFFIRM Ÿ 2 de l'existence de connexion avec au moins une de ces standby
Equivalents avec paramètres de la 9.01
GUARANTEED
RAPI D
DELAYED INSTANT
PROTECTI O N PROTECTI O N
AVAILABILITY
PERFORMANCE
TO MAXIMIZE
CONTROLE DU MODE "DATA-LOSS"
V$ARCHIVE_DEST_STATUS
Ÿ archived_thread# thread number de plus récente archive reçue par la destination Ÿ archived_seq# logseq number de plus récente archive reçue par la destination Ÿ applied_thread# thread number de plus récente archive appliquée dans la destination Ÿ applied_seq# logseq number de plus récente archive appliquée dans la destination Ÿ standby_logfile_count nb total de stanfby redo logs créées sur la standby
Ÿ status Status courant de la destination
Ÿ valid Ÿ inacti ve Ÿ deferr e d Ÿ error Ÿ disable d Ÿ bad param Ÿ alternate Ÿ ful l
Ÿ type type de database destinataire des archives
Ÿ local Ÿ physical Ÿ cross-instance
Ÿ database_mode mode de database destinataire des archives
Ÿ started Ÿ mount e d Ÿ mounted-standby Ÿ ope n
Ÿ open_read-o n l y
Ÿ recovery_mode mode courant de "media recovery" de la database destinataire des archives
Ÿ idl e managed recovery inactif
Ÿ manu a l media recovery manuel
Ÿ mana g e d managed recovery actif
Ÿ destination destination d'archivage des redo logs
Ÿ protection_mode indique le mode de protection de la database
Ÿ maximum protected Ÿ maximum availability Ÿ resynchronizati o n Ÿ maximum performance Ÿ unprotect e d
id
DETECTION AUTOMATIQUE DES MANQUES D'ARCHIVES
Nouveauté.
Les manques d'archives ("archive gaps") sont automatiquement détectés et transmis.
Ce dispositif réside dans les parties "log transport services" et "log apply services".
Ce dispositif est toujours actif dans la "log transport services" au niveau du primary
Pour activer la détection d'un manque d'archives, (par exemple, suite à une coupure du réseau et à son rétablissement), le DBA doit définir les valeurs de deux nouveaux paramètres d'initialisation :
Fetch Archive Log Client à spécifier sur le primary ou autre standby FAL_SERVER = 'tnsServiceName' Fetch Archive Log Server à spécifier sur la standby FAL_CLIENT = 'tnsServiceName'
Bien voir : Le paramètre FAL_CLIENT ne peut être positionné que sur une standby : c'est ce processus qui détecte et sollicite les services de rappatriement de la part du primary
Le paramètre FAL_SERVER est traditionnellement sur la primary, mais peut également être situé sur une autre standby qui possède les fichiers d'archives requis et pourra donc être serveur éventuel pour fournir ces archives.
An archive gap is a range of archived redo logs created whenever you are unable to receive the next archived redo log generated by the primary database at the standby database. For example, an archive gap occurs when the network goes down and automatic archiving from the primary database to the standby database stops. When the network is up and running again, automatic archiving of the archived redo logs from the primary database to the standby database resumes. However, if the standby database is specified as an optional archive destination, and one or more log switches occurred at the primary site, the standby database has an archive gap. The archived redo logs that were not transmitted represent the gap. The gap is automatically detected and resolved when the missing archived redo logs are transmitted to the standby database to resolve the gap.
PRIMARY
STANDBY 1
STANDBY 2
STANDBY 9
DETECTION AUTOMATIQUE DE GAPS D'ARCHIVES
In Oracle9i, the FAL_CLIENT and
FAL_SERVERinitialization parameters allow for automatic detection and resolution of archive log gaps on the standby database. The fetch archive log (FAL) client is a component that runs on the standby server and detects any archive log gaps.
When an archive log gap is detected, it makes a request to the fetch archive log (FAL) server to retrieve the missing logs. The FAL server is a background process that is set up to service only requests from the FAL client. The FAL server is usually located on the primary database, but can reside on another standby database. Both of these parameters must be set to valid net service names for this communication process to occur. The FAL_CLIENT
parameter is the net service name that the FAL server should use to connect to the standby database, and the FAL_
SERVER parameter is the net service name that the standby database should use to connect to the FAL server.
You can query the
V$ARCHIVE_GAP view to determine if log archive gaps exist.Network
FAL_SERVER
FAL_CLIENT FAL_SERVER
FAL_CLIENT FAL_SERVER
FAL_CLIENT
FAL_SERVER V$ARCHIVE_GAP
Ÿ thread# Numéro de thread manquant Ÿ low_sequence# Borne inférieure sequence number Ÿ high_sequence# Borne supérieure sequence number
V$ARCHIVE_GAP
Ÿ thread# Numéro de thread manquant Ÿ low_sequence# Borne inférieure sequence number Ÿ high_sequence# Borne supérieure sequence number
V$ARCHIVE_GAP
Ÿ thread# Numéro de thread manquant Ÿ low_sequence# Borne inférieure sequence number Ÿ high_sequence# Borne supérieure sequence number
SURSIS D'APPLICATION DES LOGS SUR STDBY ou DELAY
Nouveauté.
Une méthode offerte pour se prémunir de la propagation des corruptions physiques et logiques des blocs véhiculés vers les standby est de demander un délai entre le moment de la réception des logs et leur application (recover) sur les datafiles de la standby.
Se préçise AU NIVEAU DE LA PRIMARY log_archive_dest_n= 'service=tns_stdby
avec le paramètre delay=nbminutes (défaut 30)
Dans le cas où une primary est soutenue par plusieurs standy, on peut décider d'appliquer des delais différents.
Dans tous les cas, les logs sont acheminées et résident bien sur standby.
Il est toujours possible de demander l'application inconditionnelle des logs AU NIVEAU DE LA STANDBY
en passant la commande : alter database recover managed standby database
NODELAY
Network connection
Mise en oeuvre d'un délai de recovery sur standby
log_archive_de ststate_n = ENABLED '
log_archive_dest_n = ' service=stdby1 ARCH DELAY=60
SCN k deb +1 SCN l deb
archi v e archi v e
SCN k deb SCN l deb
SCN k fin SCN l fin +1
membremembre membremembre
redo log redo log
redo log redo log
redo log redo log
RECOVERY APPLICABLE DANS 60 minutes
/
Repert_ 2 1 Arc_10 0 1
Arc_10 0 6 Arc_10 0 2 Repert _ 1
Repert _ 2
Arc_10 0 5 Arc_10 0 3 Arc_10 0 4 765
1112 10
8 4
12
9 3
3 secondes
/
Repert_ 2 1 Arc_10 0 1
Arc_10 0 6 Arc_10 0 2 Repert _ 1
Repert _ 2
Arc_10 0 5 Arc_10 0 3 Arc_10 0 4
log_archive_de ststate_n = ENABLED '
log_archive_dest_n = ' service=stdby1 ARCH NODELAY
archi v e archi v e
ALTER DATABASE
RECOVER MANAGED STANDBY DATABASE NODELAY Provo
que l'applicat
ion
immédia te
de toutes les archives
archi v e
FAILOVER sur ECHEC D'ARCHIVAGE
Nouveauté.
En cas d'échec d'archivage, plusieurs dispositifs existent, qui peuvent être déclenchés en cascade.
Qu'est ce qui peut provoquer un échec d'archivage ?
dans le cas des standby, par exemple, une coupure du réseau.
autre cas d'échec, depuis la 9i : atteinte du quota fixé par quota_size=nb512blksize
Niveau réessai : log_archive_dest_n='service|location ...
réessayer au bout de tant de secondes reopen=nbsecondes
se considérer en échec au bout de tant de réessais max_failure=nbret
Le délai total que l'on s'accorde pour voir l'archivage réussir à sa destination d'origine, vaut (reopen * max_failure) DANS LE CAS D'UNE DESTINATION MANDATORY, IL Y A ECHEC, SAUF SI ...
Modification de la destination alter system set log_archive_dest_n= '...'
invalidation temporaire de la destination alter system set log_archive_dest_state_n=defer ou, NOUVEAU
Niveau "failover" d'archivage alternate=log_archive_dest_p
' log_archive_de st_n = '
PREVOIR UNE DESTINATION ALTERNEE D'ARCHIVAGE EN CAS D'ECHEC D'ARCHIVAGE : ILLUSTRATION AVEC NOUVEAU CAS D'ECHEC "QUOTA_SIZE"
This example shows how to set the initialization parameter file so that a single, mandatory, local destination will automatically fail over to a different destination if any error occurs.
LOG_ARCHIVE_DEST_1=’LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2’
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2=’LOCATION=/disk2 MANDATORY’
LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
If the LOG_ARCHIVE_DEST_1 destination fails, the archiving process will automatically switch to the LOG_ARCHIVE_DEST_2 destination at the next log switch on the primary database.
log_archive_deststa t e _n = ENABLED
location=diskprim ALTERNATE=LOG_ARCHIVE_DEST_p
log_archive_de st_p = ''
log_archive_deststa t e _p = ENABLED
location=disk sec mandatory
quota_size=20000 ATTENTION,
TOUJOURS EN BLOCS DE 512 octets, QUELLES QUE SOIENT LES CARACTERISTIQUES DU DEVICE DE SORTIE ATTENTION :
QUOTA SIZE APPLICABLE QU'AVEC LOCATION
log_archive_de st_n = '' location=diskprim ALTERNATE=LOG_ARCHIVE_DEST_p
quota_size=20000
noquota_s i z e
TIME-BASED THREAD ADVANCE
Nouveauté.
A tous les cas provoquant une constitution d'archive, on ajoute une exigence horaire.
Traditionnellement, un switch de log intervient lorsque Ÿ log full
Ÿ alter system switch logfile
On rajoute un paramètre d'initialisation archive_lag_target=nbsecondes (T)
qui dicte le SWITCH de log EN FONCTION D'UN DELAI EXPLICITE.
L'objectif est de ne pas perdre plus de T secondes de production en cas de désastre et dans le cas où nos standby sont synchronisées avec les seules archivelogs.
Ceci n'est pas équivalent à faire alter system switch logfile toutes les T secondes car ... l'exigence porte sur un temps qui intègre Ÿ et le délai entre deux archivages
Ÿ et le temps d'archivage proprement dit.
Oracle estime donc en permanence si
(délai d'archivage estimé d'aprés les archivages précédents et la taille de la log courante
+ < T
délai écoulé depuis dernier archivage)
dés que dépassement, il y a archivage
EXIGENCE D'ARCHIVAGE BASEE SUR UN DELAI
Redo log buffer
commit X
X X
commit
groupe groupe
switch
ARCH
groupe
SCN k deb +1 SCN l deb
archive archive
SCN k deb SCN l deb
SCN k fin SCN l fin
+1
membremembre membremembre
redo log redo log
redo log redo log
redo log redo log
ALTER SYSTEM SWITCH LOGFILE
765 1112 10
8 4
12
9 3
ARCHIVE_LAG_TARGET = nbseco n d e s
Bien voir :
Oracle prend soin d'intégrer
Ÿ le temps estimé d'archivage en fonction de la taille de la log courante et du temps mis pour archiver les logs précédentes
Ÿ le délai écoulé depuis l'archivage précédent.
C'est la somme de ces deux temps qui ne dépasse jamais archive_lag_target.