{"id":4106,"date":"2021-04-27T08:12:00","date_gmt":"2021-04-27T08:12:00","guid":{"rendered":"https:\/\/swiv.com.br\/fsfo-fast-start-failover-operation-requested-by-dbms_dg-initiate_fs_failover\/"},"modified":"2026-05-27T20:02:32","modified_gmt":"2026-05-27T19:02:32","slug":"fsfo-fast-start-failover-operation-requested-by-dbms_dg-initiate_fs_failover","status":"publish","type":"post","link":"https:\/\/swiv.com.br\/index.php\/2021\/04\/27\/fsfo-fast-start-failover-operation-requested-by-dbms_dg-initiate_fs_failover\/","title":{"rendered":"FSFO (Fast-Start Failover Operation) requested by DBMS_DG.INITIATE_FS_FAILOVER"},"content":{"rendered":"

A package DBMS_DG permite que as aplica\u00e7\u00f5es notifiquem o primary database ou o fast-start failover target a iniciar a opera\u00e7\u00e3o de Failover, quando a aplica\u00e7\u00e3o se depara com alguma condi\u00e7\u00e3o que o justifique. Nesse artigo vamos simular essa opera\u00e7\u00e3o, tomando como refer\u00eancia o ambiente configurado neste<\/a> meu \u00faltimo post.<\/p>\n\n\n

Validando condi\u00e7\u00f5es do nosso ambiente Data Guard:<\/p>\n\n\n

\n[oracle@fornix1 ~]$ dgmgrl sys\/oracle@CORTEX\nDGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue Apr 27 04:44:22 2021\nVersion 19.3.0.0.0\n \nCopyright (c) 1982, 2019, Oracle and\/or its affiliates.  All rights reserved.\n \nWelcome to DGMGRL, type "help" for information.\nConnected to "cortex"\nConnected as SYSDBA.\nDGMGRL> SHOW CONFIGURATION;\n \nConfiguration - cortex\n \n  Protection Mode: MaxPerformance\n  Members:\n  cortex   - Primary database\n    cortexdr - (*) Physical standby database\n \nFast-Start Failover: Enabled in Potential Data Loss Mode\n \nConfiguration Status:\nSUCCESS   (status updated 39 seconds ago)\n \nDGMGRL> SHOW DATABASE CORTEX;\n \nDatabase - cortex\n \n  Role:               PRIMARY\n  Intended State:     TRANSPORT-ON\n  Instance(s):\n    cortex\n \nDatabase Status:\nSUCCESS\n \nDGMGRL> SHOW DATABASE CORTEXDR;\n \nDatabase - cortexdr\n \n  Role:               PHYSICAL STANDBY\n  Intended State:     APPLY-ON\n  Transport Lag:      0 seconds (computed 0 seconds ago)\n  Apply Lag:          0 seconds (computed 0 seconds ago)\n  Average Apply Rate: 36.00 KByte\/s\n  Real Time Query:    OFF\n  Instance(s):\n    CORTEXDR\n \nDatabase Status:\nSUCCESS\n \nDGMGRL>\n<\/pre><\/div>\n\n\n
Em paralelo podemos ficar “observando” o Observer:<\/p>\n\n\n
\nDGMGRL> EDIT DATABASE CORTEXDR SET STATE=APPLY-ON;\nSucceeded.\nDGMGRL> START OBSERVER FILE='\/home\/oracle\/CORTEXFSFO.dat';\n[W000 2021-04-27T04:43:09.600-03:00] FSFO target standby is cortexdr\nObserver 'fornix2' started\n[W000 2021-04-27T04:43:09.665-03:00] Observer trace level is set to USER\n[W000 2021-04-27T04:43:09.665-03:00] Try to connect to the primary.\n[W000 2021-04-27T04:43:09.665-03:00] Try to connect to the primary cortex.\n[W000 2021-04-27T04:43:09.878-03:00] The standby cortexdr is ready to be a FSFO target\n[W000 2021-04-27T04:43:09.878-03:00] Connection to the primary restored!\n[W000 2021-04-27T04:43:11.879-03:00] Disconnecting from database cortex.\n<\/pre><\/div>\n\n
Para simular a solicita\u00e7\u00e3o de Failover por parte da aplica\u00e7\u00e3o, podemos executar o bloco PL\/SQL abaixo, que faz a requisi\u00e7\u00e3o e recebe um retorno em c\u00f3digo sobre o efeito da execu\u00e7\u00e3o (os detalhes podem ser vistos na documenta\u00e7\u00e3o oficial AQUI<\/a>):<\/p>\n\n
\nSET SERVEROUTPUT ON\nDECLARE\n v_status INTEGER;\n v_error  VARCHAR2(300);\nBEGIN\n  v_status := dbms_dg.initiate_fs_failover('Application Failover Requested');\n  SELECT \n     DECODE(v_status,0,'normal, successful completion',\n               16646,'Fast-Start Failover is disabled',\n               16666,'unable to initiate Fast-Start Failover on a standby database',\n               16817,'unsynchronized Fast-Start Failover configuration',\n               16819,'Fast-Start Failover observer not started',\n               16820,'Fast-Start Failover observer is no longer observing this database',\n               16829,'lagging Fast-Start Failover') INTO v_error\n   FROM dual; \n  dbms_output.put_line('Actual Status = ORA-' ||v_status||' : '||v_error);\nEND;\n\/\n<\/pre><\/div>\n\n\n
Log da execu\u00e7\u00e3o:<\/p>\n\n\n
\n[oracle@fornix1 ~]$ sqlplus \/ as sysdba\n \nSQL*Plus: Release 19.0.0.0.0 - Production on Tue Apr 27 04:48:51 2021\nVersion 19.3.0.0.0\n \nCopyright (c) 1982, 2019, Oracle.  All rights reserved.\n \n \nConnected to:\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\nVersion 19.3.0.0.0\n \nSQL> SET SERVEROUTPUT ON\nDECLARE\n v_status INTEGER;\n v_error  VARCHAR2(300);\nBEGIN\n  v_status := dbms_dg.initiate_fs_failover('Application Failover Requested');\n  SELECT\n     DECODE(v_status,0,'normal, successful completion',\n               16646,'Fast-Start Failover is disabled',\n               16666,'unable to initiate Fast-Start Failover on a standby database',\n               16817,'unsynchronized Fast-Start Failover configuration',\n               16819,'Fast-Start Failover observer not started',\n               16820,'Fast-Start Failover observer is no longer observing this database',\n               16829,'lagging Fast-Start Failover') INTO v_error\n   FROM dual;\n  dbms_output.put_line('Actual Status = ORA-' ||v_status||' : '||v_error);\nEND;\n\/SQL>   2    3    4    5    6    7    8    9   10   11   12   13   14   15   16   17\nActual Status = ORA-0 : normal, successful completion\n \nPL\/SQL procedure successfully completed.\n \nSQL>\n<\/pre><\/div>\n\n\n
Eis que j\u00e1 podemos ver no Observer que a opera\u00e7\u00e3o de Failover foi disparada:<\/p>\n\n\n
\n2021-04-27T04:49:36.826-03:00\nInitiating Fast-Start Failover to database "cortexdr"...\n[S002 2021-04-27T04:49:36.826-03:00] Initiating Fast-start Failover.\nPerforming failover NOW, please wait...\n<\/pre><\/div>\n\n\n
Failover executado com sucesso:<\/p>\n\n\n
\n2021-04-27T04:49:36.826-03:00\nInitiating Fast-Start Failover to database "cortexdr"...\n[S002 2021-04-27T04:49:36.826-03:00] Initiating Fast-start Failover.\nPerforming failover NOW, please wait...\nFailover succeeded, new primary is "cortexdr"\n2021-04-27T04:50:19.630-03:00\n[S002 2021-04-27T04:50:19.630-03:00] Fast-Start Failover finished...\n[W000 2021-04-27T04:50:19.630-03:00] Failover succeeded. Restart pinging.\n[W000 2021-04-27T04:50:20.050-03:00] Primary database has changed to cortexdr.\n[W000 2021-04-27T04:50:20.050-03:00] New standby database will not be reinstated.\n[W000 2021-04-27T04:50:20.051-03:00] Try to connect to the primary.\n[W000 2021-04-27T04:50:20.051-03:00] Try to connect to the primary cortexdr.\n[W000 2021-04-27T04:50:20.371-03:00] The standby cortex needs to be reinstated\n[W000 2021-04-27T04:50:20.371-03:00] Try to connect to the new standby cortex.\n[W000 2021-04-27T04:50:20.371-03:00] Connection to the primary restored!\nORA-12514: TNS:listener does not currently know of service requested in connect descriptor\n \nUnable to connect to database using cortex\n[W000 2021-04-27T04:50:22.373-03:00] Disconnecting from database cortexdr.\n[W000 2021-04-27T04:50:50.431-03:00] Try to connect to the new standby cortex.\nORA-12514: TNS:listener does not currently know of service requested in connect descriptor\n<\/pre><\/div>\n\n\n
Montando o novo standby:<\/p>\n\n\n
\n[oracle@fornix1 ~]$ sqlplus \/ as sysdba\n \nSQL*Plus: Release 19.0.0.0.0 - Production on Tue Apr 27 04:56:29 2021\nVersion 19.3.0.0.0\n \nCopyright (c) 1982, 2019, Oracle.  All rights reserved.\n \nConnected to an idle instance.\n \nSQL> startup mount;\nORACLE instance started.\n \nTotal System Global Area 2583690520 bytes\nFixed Size                  8899864 bytes\nVariable Size             553648128 bytes\nDatabase Buffers         2013265920 bytes\nRedo Buffers                7876608 bytes\nDatabase mounted.\nSQL>\n<\/pre><\/div>\n\n\n
No FSFO, seria normal ap\u00f3s disponibilizar o novo standby, j\u00e1 ser executado automaticamente o reinstate. Por\u00e9m percebi que n\u00e3o \u00e9 esse o comportamento:<\/p>\n\n\n
\nUnable to connect to database using cortex\n[W000 2021-04-27T04:56:50.979-03:00] Try to connect to the new standby cortex.\nORA-12528: TNS:listener: all appropriate instances are blocking new connections\n \nUnable to connect to database using cortex\n[W000 2021-04-27T04:57:21.029-03:00] Try to connect to the new standby cortex.\n[W000 2021-04-27T04:57:22.038-03:00] Connection to the new standby restored!\n[W000 2021-04-27T04:57:24.038-03:00] Try to connect to the new standby cortex.\n[W000 2021-04-27T04:57:26.043-03:00] Try to connect to the new standby cortex.\n[W000 2021-04-27T04:57:29.046-03:00] Try to connect to the new standby cortex.\n<\/pre><\/div>\n\n\n
Desse modo faremos o reinstate na m\u00e3o:<\/p>\n\n\n
\n[oracle@fornix1 admin]$ dgmgrl sys\/oracle@CORTEXDR\nDGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue Apr 27 05:02:16 2021\nVersion 19.3.0.0.0\n \nCopyright (c) 1982, 2019, Oracle and\/or its affiliates.  All rights reserved.\n \nWelcome to DGMGRL, type "help" for information.\nConnected to "CORTEXDR"\nConnected as SYSDBA.\nDGMGRL> REINSTATE DATABASE CORTEX;\nReinstating database "cortex", please wait...\nReinstatement of database "cortex" succeeded\nDGMGRL>\n<\/pre><\/div>\n\n\n
Processo reportado tamb\u00e9m no Observer:<\/p>\n\n\n
\n2021-04-27T05:03:21.184-03:00\n[W000 2021-04-27T05:03:22.183-03:00] Successfully reinstated database cortex.\n[W000 2021-04-27T05:03:24.189-03:00] The standby cortex needs to be reinstated\n[W000 2021-04-27T05:03:24.190-03:00] Try to connect to the new standby cortex.\n[W000 2021-04-27T05:03:27.191-03:00] Try to connect to the primary cortexdr.\n[W000 2021-04-27T05:03:27.195-03:00] The standby cortex has been reinstated.\n<\/pre><\/div>\n\n\n
Configura\u00e7\u00e3o atual do Data Guard:<\/p>\n\n\n
\nDGMGRL> SHOW CONFIGURATION;\n \nConfiguration - cortex\n \n  Protection Mode: MaxPerformance\n  Members:\n  cortexdr - Primary database\n    cortex   - (*) Physical standby database\n \nFast-Start Failover: Enabled in Potential Data Loss Mode\n \nConfiguration Status:\nSUCCESS   (status updated 23 seconds ago)\n<\/pre><\/div>\n\n\n
Realizando switchover para voltar o ambiente \u00e0s condi\u00e7\u00f5es originais:<\/p>\n\n\n
\nDGMGRL> SWITCHOVER TO CORTEX;\nPerforming switchover NOW, please wait...\nOperation requires a connection to database "cortex"\nConnecting ...\nConnected to "cortex"\nConnected as SYSDBA.\nNew primary database "cortex" is opening...\nOracle Clusterware is restarting database "cortexdr" ...\nConnected to an idle instance.\nConnected to an idle instance.\nConnected to an idle instance.\nConnected to an idle instance.\nConnected to "cortexDR"\nConnected to "cortexDR"\nSwitchover succeeded, new primary is "cortex"\nDGMGRL>\n<\/pre><\/div>\n\n
\nDGMGRL> SHOW CONFIGURATION;\n \nConfiguration - cortex\n \n  Protection Mode: MaxPerformance\n  Members:\n  cortex   - Primary database\n    cortexdr - (*) Physical standby database\n \nFast-Start Failover: Enabled in Potential Data Loss Mode\n \nConfiguration Status:\nSUCCESS   (status updated 24 seconds ago)\n<\/pre><\/div>\n\n\n
Obs: Este procedimento foi criado pelo senhor Ahmed Baraka (www.ahmedbaraka.com) e foi apenas reproduzido por mim em um laborat\u00f3rio pessoal para fins de aprendizado.<\/p>\n","protected":false},"excerpt":{"rendered":"
A package DBMS_DG permite que as aplica\u00e7\u00f5es notifiquem o primary database ou o fast-start failover target a iniciar a opera\u00e7\u00e3o de Failover, quando a aplica\u00e7\u00e3o se depara com alguma condi\u00e7\u00e3o que o justifique. Nesse artigo vamos simular essa opera\u00e7\u00e3o, tomando como refer\u00eancia o ambiente configurado neste meu \u00faltimo post. Validando condi\u00e7\u00f5es do nosso ambiente Data […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-4106","post","type-post","status-publish","format-standard","hentry","category-high-availability"],"_links":{"self":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/4106","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/comments?post=4106"}],"version-history":[{"count":1,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/4106\/revisions"}],"predecessor-version":[{"id":9158,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/4106\/revisions\/9158"}],"wp:attachment":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/media?parent=4106"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/categories?post=4106"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/tags?post=4106"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}