Este artigo explorar\u00e1 algumas formas para monitorarmos o Data Guard, e para simular um m\u00ednimo de opera\u00e7\u00f5es sendo executadas no primary, faremos a cria\u00e7\u00e3o de alguns objetos para execu\u00e7\u00e3o de DML rand\u00f4mico.<\/p>\n\n\n\n
Criando a tabela no banco primary que sofrer\u00e1 as altera\u00e7\u00f5es:<\/p>\n\n\n
\n[oracle@fornix1 ~]$ sqlplus \/ as sysdba\n \nSQL*Plus: Release 19.0.0.0.0 - Production on Wed Apr 7 04:07:46 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> ALTER USER HR IDENTIFIED BY oracle;\n \nUser altered.\n \nSQL> ALTER USER HR ACCOUNT UNLOCK;\n \nUser altered.\n \nSQL> CONN HR\/oracle\nConnected.\nSQL> SHOW USER;\nUSER is "HR"\nSQL> CREATE TABLE HR.NAMES ( ID NUMBER, NAME VARCHAR2(50), HDATE DATE, SAL NUMBER, REGION VARCHAR2(1));\n \nTable created.\n \nSQL> CREATE SEQUENCE S CACHE 1000;\n \nSequence created.\n<\/pre><\/div>\n\n\nCriando uma package que cont\u00e9m 2 procedures que executam os processos de DML, com o seguinte script:<\/p>\n\n\n
\n\/* Create Random Load Package *\/\nCREATE OR REPLACE PACKAGE LOAD_GENERATOR \nIS \n -- insert random rows in NAMES table\n PROCEDURE INSERT_NAMES ( P_ROWS IN NUMBER);\n -- random DML on NAMES \n PROCEDURE RandomDML(P_ITERATION IN NUMBER, P_MAX IN NUMBER); \nEND load_generator;\n\/\n \nCREATE OR REPLACE PACKAGE Body LOAD_GENERATOR\nIS\n -- generate random text: its lengnth between 4 and the passed value\n FUNCTION G_TEXT(P_SIZE IN NUMBER) RETURN VARCHAR2\n IS\n V VARCHAR2(2000);\n BEGIN\n FOR I IN 1..DBMS_RANDOM.VALUE(4,P_SIZE) LOOP\n V := V || CHR(ROUND(DBMS_RANDOM.VALUE(65,90))); -- 122\n END LOOP;\n RETURN V;\n END;\n \n PROCEDURE INSERT_NAMES ( P_ROWS IN NUMBER)\n IS\n V1 VARCHAR2(15);\n V2 VARCHAR2(15);\n BEGIN\n FOR I IN 1..P_ROWS LOOP\n V1 := G_TEXT(15);\n V2 := G_TEXT(15);\n INSERT INTO NAMES VALUES ( S.NEXTVAL, -- ID\n V1 || ' ' || V2, -- NAME\n TRUNC(SYSDATE-DBMS_RANDOM.VALUE(60,1800)), -- HDATE\n ROUND(DBMS_RANDOM.VALUE(1000,55000)), -- SAL\n DECODE( TO_CHAR(ROUND(DBMS_RANDOM.VALUE(1,4))), '1','N','2','W','3','E','4','S') ); -- REGION\n IF MOD(I,100) = 0 THEN\n COMMIT;\n END IF;\n END LOOP;\n COMMIT;\n END INSERT_NAMES;\n \n PROCEDURE RandomDML(P_ITERATION IN NUMBER, P_MAX IN NUMBER)\n IS\n N NUMBER;\n M NUMBER;\n V_NEW_SAL NUMBER;\n V1 VARCHAR2(15);\n V2 VARCHAR2(15);\n BEGIN\n FOR I IN 1.. P_ITERATION LOOP\n N := ROUND(DBMS_RANDOM.VALUE(1,3));\n IF N=1 THEN\n V1 := G_TEXT(15);\n V2 := G_TEXT(15);\n INSERT INTO NAMES VALUES ( S.NEXTVAL, -- ID\n V1 || ' ' || V2, -- NAME\n TRUNC(SYSDATE)-DBMS_RANDOM.VALUE(60,1800), -- HDATE\n ROUND(DBMS_RANDOM.VALUE(1000,55000)), -- SAL\n DECODE( TO_CHAR(ROUND(DBMS_RANDOM.VALUE(1,4))), '1','N','2','W','3','E','4','S') ); -- REGION\n ELSIF N=2 THEN\n M := ROUND(DBMS_RANDOM.VALUE(1,P_MAX));\n V_NEW_SAL := ROUND(DBMS_RANDOM.VALUE(1000,55000));\n UPDATE NAMES SET SAL = V_NEW_SAL\n WHERE ID = M;\n ELSIF N=3 THEN\n M := ROUND(DBMS_RANDOM.VALUE(1,P_MAX));\n DELETE NAMES WHERE ID = M;\n END IF; \n -- DBMS_LOCK.SLEEP(ROUND(DBMS_RANDOM.VALUE(0.1,2),2));\n COMMIT;\n END LOOP; \n END RandomDML;\nEND load_generator; \n\/\n<\/pre><\/div>\n\n\nPackage created.\n \nSQL> SQL> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66\nPackage body created.\n<\/pre><\/div>\n\n\nCriando um arquivo sql com o comando que dispara os processos criados acima:<\/p>\n\n\n
\n[oracle@fornix1 ~]$ cd ~\n[oracle@fornix1 ~]$ cat loaddml.sql\nbegin\nhr.LOAD_GENERATOR.RANDOMDML (&1, &2);\nend;\n\/\n[oracle@fornix1 ~]$\n<\/pre><\/div>\n\n\nCriando arquivo shell que aceita 3 argumentos: n\u00famero de conex\u00f5es, n\u00famero de itera\u00e7\u00f5es e n\u00famero de linhas:<\/p>\n\n\n
\n[oracle@fornix1 ~]$ cd ~\n[oracle@fornix1 ~]$ chmod +x loaddml.sh\n[oracle@fornix1 ~]$ cat loaddml.sh\n#!\/bin\/bash\n# apply random DML load on Oracle DB\n# parameters: 1 connections, 2 Iterations, 3 rows in names\nusers=$1\nSRVC="cortex"\nUNPW="hr\/oracle"\nSQLCMD="\/home\/oracle\/loaddml.sql"\nx=1\ny=$users\nITER=$2\nMAX=$3\n \nwhile [ $x -le $y ]\n do\n sqlplus -s $UNPW@$SRVC @$SQLCMD $ITER $MAX &\n x=`expr $x + 1`\ndone\n[oracle@fornix1 ~]$\n<\/pre><\/div>\n\n\nRealizando teste de execu\u00e7\u00e3o (com 5 conex\u00f5es, 2000 itera\u00e7\u00f5es e 100000 linhas na tabela HR.NAMES):<\/p>\n\n\n
\n[oracle@fornix1 ~]$ .\/loaddml.sh 5 2000 100000\n[oracle@fornix1 ~]$ old 2: hr.LOAD_GENERATOR.RANDOMDML (&1, &2);\nnew 2: hr.LOAD_GENERATOR.RANDOMDML (2000, 100000);\nold 2: hr.LOAD_GENERATOR.RANDOMDML (&1, &2);\nnew 2: hr.LOAD_GENERATOR.RANDOMDML (2000, 100000);\nold 2: hr.LOAD_GENERATOR.RANDOMDML (&1, &2);\nnew 2: hr.LOAD_GENERATOR.RANDOMDML (2000, 100000);\nold 2: hr.LOAD_GENERATOR.RANDOMDML (&1, &2);\nnew 2: hr.LOAD_GENERATOR.RANDOMDML (2000, 100000);\nold 2: hr.LOAD_GENERATOR.RANDOMDML (&1, &2);\nnew 2: hr.LOAD_GENERATOR.RANDOMDML (2000, 100000);\n \nPL\/SQL procedure successfully completed.\n \n \nPL\/SQL procedure successfully completed.\n \n \nPL\/SQL procedure successfully completed.\n \n \nPL\/SQL procedure successfully completed.\n \n \nPL\/SQL procedure successfully completed.\n<\/pre><\/div>\n\n\nMonitorando o Data Guard usando o Alert.log:<\/h2>\n\n\n\n
Qualquer erro reportado pelo DG ser\u00e1 apresentado no arquivo Alert.log. Na situa\u00e7\u00e3o abaixo, deixei o ambiente stadby down, e fui observar o alert do primary. Geralmente os DBAs criam monitoramentos procurando pelo erro ORA-, ou em casos espec\u00edficos abaixo sobre algum problema de “no listener”:<\/p>\n\n\n
\n[grid@fornix2 ~]$ crsctl stat res -t\nCRS-4639: Could not contact Oracle High Availability Services\nCRS-4000: Command Status failed, or completed with errors.\n[grid@fornix2 ~]$\n<\/pre><\/div>\n\n\n[oracle@fornix1 trace]$ cd \/oracle\/19.3.0\/base\/diag\/rdbms\/cortex\/cortex\/trace\n[oracle@fornix1 trace]$ tail -20f alert_cortex.log\n \nFatal NI connect error 12541, connecting to:\n (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=fornix2.localdomain)(PORT=1522))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=cortexDR.localdomain)(CID=(PROGRAM=oracle)(HOST=fornix1)(USER=oracle))))\n \n VERSION INFORMATION:\n TNS for Linux: Version 19.0.0.0.0 - Production\n TCP\/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production\n Version 19.3.0.0.0\n Time: 07-APR-2021 04:28:40\n Tracing not turned on.\n Tns error struct:\n ns main err code: 12541\n \nTNS-12541: TNS:no listener\n ns secondary err code: 12560\n nt main err code: 511\n \nTNS-00511: No listener\n nt secondary err code: 111\n nt OS err code: 0\n<\/pre><\/div>\n\n\n Monitorando o Data Guard usando a V$DATAGUARD_STATUS<\/h2>\n\n\n\n
Essa view nos reporta as \u00faltimas 256 mensagens (incluindo os erros) no alert.log que s\u00e3o relacionados com o physical standby, conforme exemplo abaixo:<\/p>\n\n\n
\nALTER SESSION SET NLS_DATE_FORMAT='DD-Mon-RR HH12:MI AM';\nALTER SESSION SET NLS_DATE_LANGUAGE=AMERICAN;\n \nSELECT FACILITY, ERROR_CODE, TIMESTAMP, MESSAGE\nFROM V$DATAGUARD_STATUS\nWHERE TRUNC(TIMESTAMP)= TRUNC(SYSTIMESTAMP)\nORDER BY TIMESTAMP;\n<\/pre><\/div>\n\n\n[oracle@fornix1 trace]$ sqlplus \/ as sysdba\n \nSQL*Plus: Release 19.0.0.0.0 - Production on Wed Apr 7 04:34:28 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> ALTER SESSION SET NLS_DATE_FORMAT='DD-Mon-RR HH12:MI AM';\nALTER SESSION SET NLS_DATE_LANGUAGE=AMERICAN;\n \nSELECT FACILITY, ERROR_CODE, TIMESTAMP, MESSAGE\nFROM V$DATAGUARD_STATUS\nWHERE TRUNC(TIMESTAMP)= TRUNC(SYSTIMESTAMP)\nORDER BY TIMESTAMP;\nSession altered.\n \nSQL>\nSession altered.\n \nSQL> SQL> 2 3 4\n \nFACILITY ERROR_CODE TIMESTAMP\n------------------------ ---------- ------------------\nMESSAGE\n--------------------------------------------------------------------------------\nLog Transport Services 0 07-Apr-21 03:49 AM\nRedo network throttle feature is disabled at mount time\n \nLog Transport Services 0 07-Apr-21 03:49 AM\nSTARTING ARCH PROCESSES\n \nLog Transport Services 0 07-Apr-21 03:49 AM\nSTARTING ARCH PROCESSES COMPLETE\n \n \nFACILITY ERROR_CODE TIMESTAMP\n------------------------ ---------- ------------------\nMESSAGE\n--------------------------------------------------------------------------------\nLog Transport Services 12541 07-Apr-21 04:33 AM\nError 12541 received logging on to the standby\n \nLog Transport Services 12541 07-Apr-21 04:33 AM\nCheck whether the listener is up and running.\n \nLog Transport Services 12541 07-Apr-21 04:34 AM\nError 12541 received logging on to the standby\n<\/pre><\/div>\n\n\nDetectando Archive Log GAP<\/h2>\n\n\n\n
Executando o script abaixo no standby, podemos identificar se existe gaps de archive logs no Data Guard:<\/p>\n\n\n
\n[oracle@fornix2 ~]$ sqlplus \/ as sysdba\n \nSQL*Plus: Release 19.0.0.0.0 - Production on Wed Apr 7 04:42:17 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> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;\n \nno rows selected\n<\/pre><\/div>\n\n\nOs scripts abaixo s\u00e3o mais alternativas de encontrar gaps, sendo executados no primary:<\/p>\n\n\n\n
Archive logs mais recentes no primary:<\/p>\n\n\n
\nSQL> SELECT MAX(SEQUENCE#), THREAD#\nFROM V$ARCHIVED_LOG\nWHERE RESETLOGS_CHANGE# = (SELECT MAX(RESETLOGS_CHANGE#) FROM V$ARCHIVED_LOG)\nGROUP BY THREAD#; 2 3 4\n \nMAX(SEQUENCE#) THREAD#\n-------------- ----------\n 67 1\n<\/pre><\/div>\n\n\nArchive log mais recente a ser transferido para o Standby:<\/p>\n\n\n
\nSQL> SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#\nFROM V$ARCHIVE_DEST_STATUS WHERE STATUS <> 'DEFERRED' AND STATUS <> 'INACTIVE'; 2\n \nDESTINATION\n--------------------------------------------------------------------------------\nSTATUS ARCHIVED_THREAD# ARCHIVED_SEQ#\n--------- ---------------- -------------\n+DG_RECO\nVALID 1 67\n \ncortexdr\nVALID 1 67\n<\/pre><\/div>\n\n\nValidando o transport e apply Lag<\/h2>\n\n\n\n
Rodando o comando abaixo no standby, podemos checar se existe Lag na camada de transport ou apply (em meu exemplo, deixei o Redo apply como OFF e rodei o shell script mencionado no in\u00edcio do artigo para gerar um lag m\u00ednimo de Apply):<\/p>\n\n\n
\nSQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-Mon-RR HH12:MI AM';\nALTER SESSION SET NLS_DATE_LANGUAGE=AMERICAN;\n \nSELECT NAME, VALUE, UNIT, TIME_COMPUTED\nFROM V$DATAGUARD_STATS\nWHERE NAME IN ('transport lag','apply lag','apply finish time');\nSession altered.\n \nSQL>\nSession altered.\n \nSQL> SQL> 2 3\n \nNAME\n--------------------------------\nVALUE\n----------------------------------------------------------------\nUNIT TIME_COMPUTED\n------------------------------ ------------------------------\ntransport lag\n+00 00:00:00\nday(2) to second(0) interval 04\/07\/2021 05:05:33\n \napply lag\n+00 00:01:05\nday(2) to second(0) interval 04\/07\/2021 05:05:33\n \nNAME\n--------------------------------\nVALUE\n----------------------------------------------------------------\nUNIT TIME_COMPUTED\n------------------------------ ------------------------------\n \napply finish time\n+00 00:00:05.610\nday(2) to second(3) interval 04\/07\/2021 05:05:33\n<\/pre><\/div>\n\n\nHabilitando o Redo Apply:<\/p>\n\n\n
\n[oracle@fornix2 ~]$ dgmgrl sys\/oracle@CORTEXDR\nDGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Apr 7 05:00:04 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> EDIT DATABASE CORTEXDR SET STATE=APPLY-ON;\nSucceeded.\n<\/pre><\/div>\n\n\nRealizando novamente a consulta:<\/p>\n\n\n
\nSQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-Mon-RR HH12:MI AM';\nALTER SESSION SET NLS_DATE_LANGUAGE=AMERICAN;\n \nSELECT NAME, VALUE, UNIT, TIME_COMPUTED\nFROM V$DATAGUARD_STATS\nWHERE NAME IN ('transport lag','apply lag','apply finish time');\nSession altered.\n \nSQL>\nSession altered.\n \nSQL> SQL> 2 3\n \nNAME\n--------------------------------\nVALUE\n----------------------------------------------------------------\nUNIT TIME_COMPUTED\n------------------------------ ------------------------------\ntransport lag\n+00 00:00:00\nday(2) to second(0) interval 04\/07\/2021 05:06:46\n \napply lag\n+00 00:00:00\nday(2) to second(0) interval 04\/07\/2021 05:06:46\n \nNAME\n--------------------------------\nVALUE\n----------------------------------------------------------------\nUNIT TIME_COMPUTED\n------------------------------ ------------------------------\n \napply finish time\n+00 00:00:00.000\nday(2) to second(3) interval 04\/07\/2021 05:06:46\n<\/pre><\/div>\n\n\nTamb\u00e9m \u00e9 poss\u00edvel checar a exist\u00eancia de Lags caso tenhamos configurado o Data Broker:<\/p>\n\n\n
\n[oracle@fornix2 ~]$ dgmgrl sys\/oracle@CORTEXDR\nDGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Apr 7 05:08:30 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> 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: 22.00 KByte\/s\n Real Time Query: OFF\n Instance(s):\n CORTEXDR\n \nDatabase Status:\nSUCCESS\n<\/pre><\/div>\n\n\nDe forma mais detalhada, podemos ver pelo Broker tamb\u00e9m os archive logs enviados pelo primary:<\/p>\n\n\n
\n[oracle@fornix1 ~]$ dgmgrl sys\/oracle@CORTEX\nDGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Apr 7 05:11:13 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 DATABASE CORTEX SendQEntries;\nPRIMARY_SEND_QUEUE\n STANDBY_NAME STATUS RESETLOGS_ID THREAD LOG_SEQ TIME_GENERATED TIME_COMPLETED FIRST_CHANGE# NEXT_CHANGE# SIZE (KBs)\n CURRENT 1039033628 1 70 04\/07\/2021 05:05:24 5786739 275\n<\/pre><\/div>\n\n\nValidando pelo Broker os archive logs recebidos pelo standby mas que n\u00e3o foram aplicados:<\/p>\n\n\n
\n[oracle@fornix2 ~]$ dgmgrl sys\/oracle@CORTEXDR\nDGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Apr 7 05:12:49 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> SHOW DATABASE CORTEXDR RECVQENTRIES;\nSTANDBY_RECEIVE_QUEUE\n STATUS RESETLOGS_ID THREAD LOG_SEQ TIME_GENERATED TIME_COMPLETED FIRST_CHANGE# NEXT_CHANGE# SIZE (KBs)\n \nDGMGRL>\n<\/pre><\/div>\n\n\nMonitorando processos em execu\u00e7\u00e3o do Data Guard<\/h2>\n\n\n\n
Ao executar o comando abaixo no standby, podemos ter os detalhes dos processos que est\u00e3o compondo a solu\u00e7\u00e3o de Data Guard em nosso ambiente:<\/p>\n\n\n
\n[oracle@fornix2 ~]$ sqlplus \/ as sysdba\n \nSQL*Plus: Release 19.0.0.0.0 - Production on Wed Apr 7 05:16:14 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> SELECT PID, PROCESS, STATUS, CLIENT_PROCESS, CLIENT_PID, THREAD#, SEQUENCE# SEQ#, BLOCK#, BLOCKS\nFROM V$MANAGED_STANDBY\nORDER BY PROCESS; 2 3\n \nPID PROCESS STATUS CLIENT_P\n------------------------ --------- ------------ --------\nCLIENT_PID THREAD# SEQ# BLOCK#\n---------------------------------------- ---------- ---------- ----------\n BLOCKS\n----------\n10631 ARCH CLOSING ARCH\n10631 1 68 6144\n 1017\n \n10633 ARCH CONNECTED ARCH\n10633 0 0 0\n 0\n \nPID PROCESS STATUS CLIENT_P\n------------------------ --------- ------------ --------\nCLIENT_PID THREAD# SEQ# BLOCK#\n---------------------------------------- ---------- ---------- ----------\n BLOCKS\n----------\n \n10629 ARCH CLOSING ARCH\n10629 1 69 12288\n 1371\n \n10623 ARCH CONNECTED ARCH\n10623 0 0 0\n \nPID PROCESS STATUS CLIENT_P\n------------------------ --------- ------------ --------\nCLIENT_PID THREAD# SEQ# BLOCK#\n---------------------------------------- ---------- ---------- ----------\n BLOCKS\n----------\n 0\n \n10627 DGRD ALLOCATED N\/A\nN\/A 0 0 0\n 0\n \n10621 DGRD ALLOCATED N\/A\n \nPID PROCESS STATUS CLIENT_P\n------------------------ --------- ------------ --------\nCLIENT_PID THREAD# SEQ# BLOCK#\n---------------------------------------- ---------- ---------- ----------\n BLOCKS\n----------\nN\/A 0 0 0\n 0\n \n12501 MRP0 APPLYING_LOG N\/A\nN\/A 1 70 960\n 409600\n \n \nPID PROCESS STATUS CLIENT_P\n------------------------ --------- ------------ --------\nCLIENT_PID THREAD# SEQ# BLOCK#\n---------------------------------------- ---------- ---------- ----------\n BLOCKS\n----------\n10653 RFS IDLE Archival\n3699 1 0 0\n 0\n \n11330 RFS IDLE LGWR\n3713 1 70 960\n 1\n \nPID PROCESS STATUS CLIENT_P\n------------------------ --------- ------------ --------\nCLIENT_PID THREAD# SEQ# BLOCK#\n---------------------------------------- ---------- ---------- ----------\n BLOCKS\n----------\n \n \n9 rows selected.\n<\/pre><\/div>\n\n\nMonitorando taxa do Redo Apply <\/h2>\n\n\n\n
Executando o comando abaixo no standy, podemos ter acesso a algumas taxas relacionadas com o Redo Apply:<\/p>\n\n\n
\n[oracle@fornix2 ~]$ sqlplus \/ as sysdba\n \nSQL*Plus: Release 19.0.0.0.0 - Production on Wed Apr 7 05:25:57 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> SELECT START_TIME , ITEM, SOFAR || ' ' || UNITS Sofar\nFROM V$RECOVERY_PROGRESS\nWHERE ITEM IN ('Active Apply Rate', 'Average Apply Rate', 'Redo Applied'); 2 3\n \nSTART_TIME ITEM\n------------------- --------------------------------\nSOFAR\n-------------------------------------------------------------------------\n2021-04-07:05:06:37 Active Apply Rate\n0 KB\/sec\n \n2021-04-07:05:06:37 Average Apply Rate\n2 KB\/sec\n \n2021-04-07:05:06:37 Redo Applied\n3 Megabytes\n \n \nSTART_TIME ITEM\n------------------- --------------------------------\nSOFAR\n-------------------------------------------------------------------------\n2021-04-07:05:00:29 Active Apply Rate\n1179 KB\/sec\n \n2021-04-07:05:00:29 Average Apply Rate\n79 KB\/sec\n \n2021-04-07:05:00:29 Redo Applied\n18 Megabytes\n \n \n6 rows selected.\n<\/pre><\/div>\n\n\nObs: 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":"
Este artigo explorar\u00e1 algumas formas para monitorarmos o Data Guard, e para simular um m\u00ednimo de opera\u00e7\u00f5es sendo executadas no primary, faremos a cria\u00e7\u00e3o de alguns objetos para execu\u00e7\u00e3o de DML rand\u00f4mico. Criando a tabela no banco primary que sofrer\u00e1 as altera\u00e7\u00f5es: Criando uma package que cont\u00e9m 2 procedures que executam os processos de DML, […]<\/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-3557","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\/3557","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=3557"}],"version-history":[{"count":1,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/3557\/revisions"}],"predecessor-version":[{"id":9186,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/3557\/revisions\/9186"}],"wp:attachment":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/media?parent=3557"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/categories?post=3557"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/tags?post=3557"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}