Depuis Oracle 11.2, vous pouvez effectuer la configuration en mode Maximum Performance et donc avec une perte de données en cas de bascule.Avec un peu de pratique, vous pourrez mettre en place cette configuration en moins de 30 minutes Si vous n’avez pas l’habitude, appuyez-vous sur 2 de mes articles pour mettre en place la configuration Data Guard avec la commande DUPLICATE FROM ACTIVE DATABASE puis pour activer le mode Maximum Availability et tester la bascule. Pour commencer, mettez en place une configuration Data Guard en mode Maximum Availability, c’est à dire avec une réplication synchrone des logs. L’objet ici est juste d’illustrer comment la configuration fonctionne. Nous passerons les considérations d’architecture et de gestion pour assurer la fiabilité d’une telle configuration. Le troisième serveur utilise un moteur Oracle Enterprise Edition et exécute un programme appelé « Observer » lancé depuis la ligne de commande dgmgrl. Pour cela, vous devez mettre en oeuvre un troisième serveur sur un site indépendant des 2 autres et garantir que vous ne puissiez pas perdre la connectivité au site de production simultanément depuis le site de reprise et le site de surveillance. OL7-121-DG1:( ):PHYSICAL STANDBY> exitĭisconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.Cet article illustre la bascule automatique (aka Fast Start Failover) de Data Guard. With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production Note: This is not a good practice for real-world scenarios.
Welcome to DGMGRL, type "help" for information.
Validate Data Guard connectivity from all hosts: sql]$ dgmgrlĭGMGRL for Linux: Version 12.1.0.2.0 - 64bit ProductionĬopyright (c) 2000, 2013, Oracle. Thread # Smallest Online Redo Smallest Standby Redo Thread # Online Redo Log Groups Standby Redo Log Groups Status Transport Lag: 0 seconds (computed 1 second ago) Ready for Failover: Yes (Primary Running)Īpply Lag: 0 seconds (computed 1 second ago) Validate Data Guard configuration: DGMGRL> validate database verbose cdb1_stbyĬdb1_stby Standby Redo Log Files: Cleared StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ol7-121-dg1)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=cdb1_DGMGRL)(INSTANCE_NAME=cdb1)(SERVER=DEDICATED)))' Transport Lag: 0 seconds (computed 0 seconds ago)Īpply Lag: 0 seconds (computed 0 seconds ago) StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST' StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ol7-121-dg2)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=cdb1_stby_DGMGRL)(INSTANCE_NAME=cdb1)(SERVER=DEDICATED)))' Review Data Guard configuration: DGMGRL> show configuration verbose OL7-121-DG1:( ):PHYSICAL STANDBY> show parameter fal OL7-121-DG1:( ):PHYSICAL STANDBY> show parameter db%name OL7-121-DG2:( ):PRIMARY> show parameter fal Review Data Guard using sqlplus: OL7-121-DG2:( ):PRIMARY> show parameter db%name This also demonstrates why it may not be a good idea to suffix stby for standby database. Note: Primary Database: cdb1_stby is because the failover was previously performed. The same process should work for RAC environment as my colleague has used the same process to test for RAC running on ODA. The environment is a single instance database without any grid Infrastructure components. This post will demonstrate the procedure to test Oracle Data Guard Fast-Start Failover by shutting down the server where the primary database is running from.
0 kommentar(er)
