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

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

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 2/27 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 s, 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 s.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 3/27 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 s, 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.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 4/27 Nouveauté. DATA GUARD BROKER Outil de gestion dun environnement data guard Quelle structure? Interface Graphique Interface "ligne de commande" créer configurer administrer surveiller contrôler data guard manager 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, anciennement drs_sta rt

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 5/27 DATA GUARD BROKER : ANCRAGE dg_broker_config_file2 dg_broker_config_file1 dg_broker_config_file1 2 STANDBY 0 DMON dg_broker_start=true false STANDBY 1 DMON dg_broker_config_file2 dg_broker_config_file1 dg_broker_config_file dg_broker_config_file 1 PRIMARY 2 DMON dg_broker_start=true false STANDBY 2 dg_broker_config_file1 2 dg_broker_config_file1 2 dg_broker_start=true false dg_broker_config_file2 Network dg_broker_config_file1 DMON dg_broker_start=true false dg_broker_config_file1 2 STANDBY 3 DMON dg_broker_start=true false dg_broker_config_file2 dg_broker_config_file1 dg_broker_config_file1 2 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 BIEN VOIR : La modification dynamique des noms des fichiers de config doit se faire, DMON arrêté : alter system set dg_broker_start=false puis alter system set dg_broker_config_file1=... puis alter system set dg_broker_start=true

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 6/27 Nouveauté. DATABASE SWITCHOVER 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 : corruptions logiques : ce délai. ne sont pas répercutées dans les log stream, donc non véhiculées ne sont pas appliquées sur la base standby si lon a pris soin dintroduire un délai de recovery sur standby (log_archive_dest_n=service=servnam delay=nbminutes) et que la corruption intervient dans Le switchover ECHANGE LES ROLES de la PRIMARY et de la STANDBY (lune devient lautre). 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.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 7/27 SWITCHOVER : VERIFICATIONS PRIMARY STANDBY $ORACLE_HOME dbs $ORACLE_HOME dbs prim<sid>.ora prim<sid>.ora prim<sid>.ora prim<sid>.ora stdb<sid>.ora stdb<sid>.ora 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

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 8/27 SWITCHOVER : OPERATIONS SUR PRIMARY select SWITCHOVER_STATUS from V$DATABASE ; SWITCHOVER_STATUS --------------------------------------- - TO STANDBY TO STANDBY indique que la base peut être candidate à une bascule "vers standby". name V$DATABASE switchover_status TO PRIMARY SWITCHOVER PENDING TO STANDBY ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STAN DBY OPEN switchover requiert 1 seule session active. TUE OU PAS LES AUTRES SESSIONS WITH WITHOUT SESSION SHUTDOWN Départ CONTROLE RETOURNE A LA FIN DU SWITCHOVER OU IMMEDIATEMENT WAIT NOWAIT PRIMARY MOUNT standby SHUTDOWN NORMAL NOMOUNT STARTUP NOMOUNT ALTER DATABASE MOUNT STAN DBY DATABASE

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 9/27 SWITCHOVER : OPERATIONS SUR 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 quelle est prête à prendre le rôle de primary name V$DATABASE switchover_status TO PRIMARY SWITCHOVER PENDING TO STANDBY ALTER DATABASE CREATE COMMIT TO SWITCHOVER TO PRIMARY A cette occasion, création automatique des online s. OPEN switchover requiert 1 seule session active. TUE OU PAS LES AUTRES SESSIONS WITH WITHOUT SESSION SHUTDOWN CONTROLE RETOURNE A LA FIN DU SWITCHOVER OU IMMEDIATEMENT WAIT NOWAIT Départ MOUNT standby STANDBY SHUTDOWN STARTUP 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. name V$DATABASE switchover_status TO PRIMARY SWITCHOVER PENDING TO STANDBY

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 10/27 SWITCHOVER : OPERATIONS FINALES NOUVELLE STANDBY (ancienne primary) 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 managed recovery. This causes control to be 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. ALTER SYSTEM ARCHIVE LOG START NOUVELLE PRIMARY (ancienne standby) groupe ARCH switch groupe groupe SCN k deb SCN k fin +1 SCN l deb SCN l fin archive archive ALTER SYSTEM SWITCH LOGFILE

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 11/27 Nouveauté. PHYSICAL STANDBY VS LOGICAL STANDBY La standby database telle quen 8i est une PHYSICAL STANDBY DATABASE, au sens où elle est maintenue à jour sur la base dune SIMILARITE BLOC TO BLOC basée sur les adresses physiques en 9i, on a la possibilité davoir 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.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 12/27 Nouveauté. LOG TRANSPORT SERVICES Jusquen 8i, la synchronisation de la primary database et de la standby database ne se faisait quà travers les échanges darchives 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 darchives sur la standby, grace à laction 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 lexigence dans archive_log_dest_n Dans le cas de lasynchrone, 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 dexigences 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 ou quelles se fassent en série avec atente déventuelles confirmations PARALLEL NOPARALLEL

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 13/27 Les trois modes de véhiculage des modifications commitées : synchronous DCM, asynchronous DCM & batched DCM log_archive_dest_n = service=stdby1 ARCH SYNC log_archive_deststate_n = ENABLED X X X commit commit Redo log buffer RECOVERY PASSIF sourd archives / Repert_1 SAVOIR : Repert_2 Repert_21 full groupe switch groupe groupe sync peut être accompagné de la clause AFFIRM ou NOAFFIRM. en fait, par défaut, laknowledge nest émis quà bonne réception de larchived log. pour confirmation liée à constituion complète sur distant, inscrire AFFIRM. Arc_1001 Arc_1002 Arc_1003 Arc_1004 Arc_1005 Arc_1006 standby_archive_dest=dest SCN k deb SCN k fin archive +1 SCN l deb SCN l fin archive membre membre membre membre Network connection archive ARC3 ARC2 ARC1 RFS3 RFS2 RFS1

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 14/27 Les trois modes de véhiculage des modifications commitées : synchronous DCM, asynchronous DCM & batched DCM log_archive_dest_n = service=stdby1 LGWR SYNC log_archive_deststate_n = ENABLED SAVOIR : X X X commit commit Redo log buffer LGWR ecriture OK Network connection ecriture OK COMMIT 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, laknowledge nest émis quà bonne réception du vecteur log. pour confirmation liée à écriture physique, inscrire AFFIRM. BIEN VOIR : Process serveur aknowledge Aucune donnée "primary" nest 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. BIEN VOIR : Cest à travers le paramètre log_archive_dest_n que lon préçise que cest 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.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 15/27 Les trois modes de véhiculage des modifications commitées : synchronous DCM, asynchronous DCM & batched DCM log_archive_dest_n = service=stdby1 LGWR ASYNC log_archive_deststate_n = ENABLED X X commit Network connection : write request X commit Redo log buffer Shipping Slave SAVOIR : async peut être accompagné de la clause AFFIRM ou NOAFFIRM. LGWR RFS ecritu re OK BIEN VOIR : COMMIT Process serveur aknowledge les données redo sont transportées "dés que possible" vers le site standby distant Pas doverheads entraînés par lécriture distante Toute database sinistrée nest pas garantie récupérable A LINSTANT MEME du SINISTRE. BIEN VOIR : Cest à travers le paramètre log_archive_dest_n que lon préçise que cest 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 online sera effectuée, sans attendre confirmation écriture distante.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 16/27 synchronous DCM, asynchronous DCM et degrés de fiabilité log_archive_dest_n = service=stdby1 LGWR async sync affirm Perf prim db : hautes niveau sécu datas par stdby : faible Perf prim db : minimal niveau sécu datas par stdby : maximal noaffirm Perf prim db : maximal niveau sécu datas par stdby : minimal Perf prim db : faibles niveau sécu datas par stdby : haut parallel noparallel 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

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 17/27 Nouveauté. CONFIGURER EN MODE "no-data-loss" 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 à loccasion dun failover, alors quil existait une data divergence. TRAVAILLER EN NO-DATA-LOSS implique lutilisation dun 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 quil nexiste 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 sarrête. Une transaction ne peut pas commiter jusquà ce que toutes les données nécessaires au recover de cette transaction, naient été écrites AU MOINS SUR UNE PHYSICAL STANDBY configurée en SYNC log transport mode.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 18/27 MODE NO-DATA-LOSS ALTER DATABASE SET STANDBY PROTECTION 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 TO MAXIMIZE AVAILABILITY 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. PERFORMANCE 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 quune standby à la fois. TO MAXIMIZE PROTECTION ou TO MAXIMIZE AVAILABILITY fixent le comportement du primary vis à vis de lensemble des standby, dont certaines peuvent être en SYNC et dautres non. Ces 2 modes sintéressent aux standby en mode SYNC. La garantie provient du fait que la VIE de la primary dépend 1 de lexistence de standby MANDATORY/LGWR/SYNC/AFFIRM 2 de lexistence de connexion avec au moins une de ces standby PROTECTION GUARANTEED TO MAXIMIZE AVAILABILITY INSTANT PROTECTION RAPID PERFORMANCE DELAYED Equivalents avec paramètres de la 9.01

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 19/27 CONTROLE DU MODE "DATA-LOSS" id V$ARCHIVE_DEST_STATUS archived_thread# archived_seq# applied_thread# applied_seq# standby_logfile_count status valid inactive deferred error disabled bad param alternate full type local physical cross-instance database_mode started mounted mounted-standby open open_read-only recovery_mode archives idle manual managed destination protection_mode maximum protected maximum availability resynchronization maximum performance unprotected thread number de plus récente archive reçue par la destination logseq number de plus récente archive reçue par la destination thread number de plus récente archive appliquée dans la destination logseq number de plus récente archive appliquée dans la destination nb total de stanfby s créées sur la standby Status courant de la destination type de database destinataire des archives mode de database destinataire des archives mode courant de "media recovery" de la database destinataire des managed recovery inactif media recovery manuel managed recovery actif destination darchivage des s indique le mode de protection de la database

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 20/27 DETECTION AUTOMATIQUE DES MANQUES Nouveauté. DARCHIVES Les manques darchives ("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 dun manque darchives, (par exemple, suite à une coupure du réseau et à son rétablissement), le DBA doit définir les valeurs de deux nouveaux paramètres dinitialisation : 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 : cest 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 darchives requis et pourra donc être serveur éventuel pour fournir ces archives. An archive gap is a range of archived s created whenever you are unable to receive the next archived 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 s that were not transmitted represent the gap. The gap is automatically detected and resolved when the missing archived s are transmitted to the standby database to resolve the gap.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 21/27 DETECTION AUTOMATIQUE DE GAPS DARCHIVES PRIMARY FAL_SERVER FAL_CLIENT STANDBY 1 V$ARCHIVE_GAP thread# Numéro de thread manquant low_sequence# Borne inférieure sequence number high_sequence# Borne supérieure sequence number FAL_SERVER Network FAL_SERVER FAL_CLIENT STANDBY 2 V$ARCHIVE_GAP thread# Numéro de thread manquant low_sequence# Borne inférieure sequence number high_sequence# Borne supérieure sequence number FAL_SERVER FAL_CLIENT STANDBY 9 V$ARCHIVE_GAP thread# Numéro de thread manquant low_sequence# Borne inférieure sequence number high_sequence# Borne supérieure sequence number 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.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 22/27 SURSIS DAPPLICATION DES LOGS SUR STDBY Nouveauté. ou DELAY 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 dappliquer 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 lapplication inconditionnelle des logs AU NIVEAU DE LA STANDBY en passant la commande : alter database recover managed standby database NODELAY

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 23/27 Mise en oeuvre dun délai de recovery sur standby log_archive_dest_n = service=stdby1 ARCH DELAY=60 Provo que lapplicat ion immédia te de toutes les archi ves log_archive_deststate_n = ENABLED ALTER DATABASE log_archive_dest_n log_archive_deststate_n = service=stdby1 ARCH NODELAY = ENABLED RECOVER MANAGED STANDBY DATABASE NODELAY SCN k deb SCN k fin +1 SCN l deb SCN l fin membre membre membre membre RECOVERY APPLICABLE DANS 60 minutes 11 12 1 10 2 9 3 8 4 7 6 5 3 secondes / Repert_1 Repert_2 Repert_21 archive archive archive Arc_1001 Arc_1002 Arc_1003 archive Arc_1004 Network connection Arc_1005 Arc_1006 archive / Repert_1 Repert_2 Repert_21 Arc_1001 Arc_1002 Arc_1003 Arc_1004 Arc_1005 Arc_1006

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 24/27 Nouveauté. FAILOVER sur ECHEC DARCHIVAGE En cas déchec darchivage, plusieurs dispositifs existent, qui peuvent être déclenchés en cascade. Quest ce qui peut provoquer un échec darchivage? 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 lon saccorde pour voir larchivage réussir à sa destination dorigine, vaut (reopen * max_failure) DANS LE CAS DUNE DESTINATION MANDATORY, IL Y A ECHEC, SAUF SI... Modification de la destination invalidation temporaire de la destination ou, NOUVEAU Niveau "failover" darchivage alter system set log_archive_dest_n=... alter system set log_archive_dest_state_n=defer alternate=log_archive_dest_p

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 25/27 PREVOIR UNE DESTINATION ALTERNEE DARCHIVAGE EN CAS DECHEC DARCHIVAGE : ILLUSTRATION AVEC NOUVEAU CAS DECHEC "QUOTA_SIZE" quota_size=20000 log_archive_dest_n = location=diskprim ALTERNATE=LOG_ARCHIVE_DEST_p noquota_size ATTENTION : QUOTA SIZE APPLICABLE QUAVEC LOCATION ATTENTION, TOUJOURS EN BLOCS DE 512 octets, QUELLES QUE SOIENT LES CARACTERISTIQUES DU DEVICE DE SORTIE log_archive_dest_n = location=diskprim ALTERNATE=LOG_ARCHIVE_DEST_p quota_size=20000 log_archive_deststate_n = ENABLED log_archive_dest_p = location=disksec mandatory log_archive_deststate_p = ENABLED 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.

Oracle upg adm 9i Claude DA COSTA Chap 5 Data Protection and Disaster Recovery Page 26/27 Nouveauté. TIME-BASED THREAD ADVANCE A tous les cas provoquant une constitution darchive, on ajoute une exigence horaire. Traditionnellement, un switch de log intervient lorsque log full alter system switch logfile On rajoute un paramètre dinitialisation qui dicte le SWITCH de log EN FONCTION DUN DELAI EXPLICITE. archive_lag_target=nbsecondes (T) Lobjectif 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 nest pas équivalent à faire alter system switch logfile toutes les T secondes car... lexigence porte sur un temps qui intègre et le délai entre deux archivages et le temps darchivage proprement dit. Oracle estime donc en permanence si (délai darchivage estimé dapré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