Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 1/27. DATA PROTECTION and DISASTER RECOVERY

(1)

DATA PROTECTION and

DISASTER RECOVERY

(2)

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.

(3)

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.

(4)

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

=filespec

Comment démarrer ? DGMGRL

dg_broker_star

t, anciennem

ent drs_sta rt

(5)

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|2 dg_broker_star t =true|fals e

dg_broker_config_file2 DMON

dg_broker_config_file1|2 dg_broker_star t =true|fals e

DMON dg_broker_config_file1

dg_broker_config_file1|2 dg_broker_star t =true|fals e

(6)

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.

(7)

SWITCHOVER : VERIFICATIONS

dbs

prim<sid>.ora

$ORACLE_HOME

stdb<sid>.ora

PRIMARY STANDBY

dbs

prim<sid>.ora

$ORACLE_HOME

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

(8)

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

COMM I T TO

SWITCHOVER TO PHYSICAL STAN D B Y

(9)

SWITCHOVER : OPERATIONS SUR STANDBY

STANDBY

--- -

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

--- -

TO STANDBY

TO STANDBY indique que la base est primary et que son prochain état possible est STANDBY.

V$DATABASE

na m e

V$DATABASE

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

CREATE

Départ

COMM I T TO

SWITCHOVER TO PRIM A R Y

(10)

SWITCHOVER : OPERATIONS FINALES

NOUVELLE STANDBY

(a nc ie

nn e

pr im ar y)

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

(11)

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.

(12)

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

(13)

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

archi v e archi v e

SCN k fin SCN l fin +1

membremembre membremembre

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

(14)

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.

LGWR

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.

(15)

Shipping Slave

Network connection : write request

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

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.

(16)

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

(17)

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.

(18)

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

(19)

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

(20)

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.

(21)

PRIMARY

STANDBY 1

STANDBY 2

STANDBY 9

DETECTION AUTOMATIQUE DE GAPS D'ARCHIVES

In Oracle9i, the FAL_CLIENT and

FAL_SERVER

initialization 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 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

(22)

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

(23)

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 fin SCN l fin +1

membremembre membremembre

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

RECOVER MANAGED STANDBY DATABASE NODELAY Provo

que l'applicat

ion

immédia te

de toutes les archives

archi v e

(24)

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

(25)

' 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

(26)

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

(27)

EXIGENCE D'ARCHIVAGE BASEE SUR UN DELAI

Redo log buffer

commit X

X X

commit

groupe groupe

switch

ARCH

groupe

archive archive

SCN k fin SCN l fin

+1

membremembre membremembre

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.