Database Tutorials MSSQL, Oracle, PostgreSQL, MySQL, MariaDB, DB2, Sybase, Teradata, Big Data, NOSQL, MongoDB, Couchbase, Cassandra, Windows, Linux 
You can find the below informations about Snapshot Standby Database in this article.
- What is Oracle Snapshot Standby Database?
- Convert Physical Standby to Snapshot Standby
- Convert Physical Standby to Snapshot Standby using Dgmgrl
- Convert Snapshot Standby Back to Physical Standby
What is Oracle Snapshot Standby Database?
Snapshot Standby Database is an updatable database created from Physical Standby Database.
There is redo flow to Snapshot Standby Database, but there is no redo apply.
As soon as the Physical Standby Database is converted to Snapshot Standby Database, an implicit restore point is created and Flashback logs are activated.
Besides being a nice feature to be updated, Snapshot Standby Database also has dangerous points.
Dangerous Points of Snapshot Database
- Suppose one of the redo log files is corrupted in Snapshot Standby Database. In this case, we cannot know what the problem is until we convert it to a physical standby database and redo-apply it with the MRP process. If something happens to our Primary database at this moment, we will have a definite data loss because there is no other place to get that log.
- If Flashback Logs are corrupted or deleted, we cannot return to Physical Standby Database.
- Let’s say something happens to Primary Database while Standby Database is in Snapshot mode. In this case, it will be rewound with Flashback logs first. Since it will run the archives later, it means an interruption for as much as this time.
Physical Standby Database cannot be converted to Snapshot Standby Database in the following cases;
- If Maximum Protection mode is used and there is only one Standby Database in the Data Guard Environment. The reason is that when there is only one Standby Database, it must be sync with Primary as much as possible so that it can be Primary quickly if a Failover occurs.
- If it is the Standby Database where Fast-Start Failover will be made.
Convert Physical Standby to Snapshot Standby
Step1:
Some checks are made on the Primary and Standby sides.
1 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 | [Standby-1] SQL> select database_role from v$database; DATABASE_ROLE ---------------- PHYSICAL STANDBY SQL> select flashback_on from v$database; FLASHBACK_ON ------------------ NO SQL> show parameter DB_FLASHBACK_RETENTION_TARGET NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_flashback_retention_target integer 1440 SQL> show parameter DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string +FRA db_recovery_file_dest_size big integer 10G SQL> select file_type,number_of_files,percent_space_used from v$recovery_area_usage; FILE_TYPE NUMBER_OF_FILES PERCENT_SPACE_USED -------------------- --------------- ------------------ CONTROL FILE 0 0 REDO LOG 0 0 ARCHIVED LOG 333 88.24 BACKUP PIECE 0 0 IMAGE COPY 0 0 FLASHBACK LOG 0 0 FOREIGN ARCHIVED LOG 0 0 7 rows selected. |
1 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 | [Primary-1] SQL> select database_role from v$database; DATABASE_ROLE ---------------- PRIMARY SQL> select flashback_on from v$database; FLASHBACK_ON ------------------ NO SQL> show parameter DB_FLASHBACK_RETENTION_TARGET NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_flashback_retention_target integer 1440 SQL> show parameter DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string +FRA db_recovery_file_dest_size big integer 40G SQL> select file_type,number_of_files,percent_space_used from v$recovery_area_usage; FILE_TYPE NUMBER_OF_FILES PERCENT_SPACE_USED -------------------- --------------- ------------------ CONTROL FILE 0 0 REDO LOG 0 0 ARCHIVED LOG 338 22.15 BACKUP PIECE 0 0 IMAGE COPY 0 0 FLASHBACK LOG 0 0 FOREIGN ARCHIVED LOG 0 0 7 rows selected. |
Step2:
Stop the Redo-Apply on the Standby.
1 2 3 4 | [Standby-1] SQL> alter database recover managed standby database cancel; Database altered. |
Step3:
Convert Physical Standby to Snapshot Standby.
1 2 3 4 | [Standby-1] SQL> alter database convert to snapshot standby; Database altered. |
Step4:
Check the databse role and Flashback status.
1 2 3 4 5 6 | [Standby-1] SQL> select database_role from v$database; DATABASE_ROLE ---------------- SNAPSHOT STANDBY |
1 2 3 4 5 6 | [Primary-1] SQL> select flashback_on from v$database; FLASHBACK_ON ------------------ NO |
1 2 3 4 5 6 | [Standby-1] SQL> select flashback_on from v$database; FLASHBACK_ON ------------------ RESTORE POINT ONLY |
Step5:
The created restore point’s storage size can be seen.
1 2 3 4 5 6 7 8 | [Standby-1] SQL> set linesize 500 SQL> column name format a50 SQL> select name, storage_size from v$restore_point; NAME STORAGE_SIZE -------------------------------------------------- ------------ SNAPSHOT_STANDBY_REQUIRED_01/05/2017 14:30:05 104857600 |
Step6:
Check databases modes.
1 2 3 4 5 6 | [Primary-1] SQL> select open_mode from v$database; OPEN_MODE -------------------- READ WRITE |
1 2 3 4 5 6 | [Standby-1] SQL> select open_mode from v$database; OPEN_MODE -------------------- MOUNTED |
Step7:
Check if the flashback logs start to created.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | [Standby-1] SQL> select file_type,number_of_files,percent_space_used from v$recovery_area_usage; FILE_TYPE NUMBER_OF_FILES PERCENT_SPACE_USED -------------------- --------------- ------------------ CONTROL FILE 0 0 REDO LOG 0 0 ARCHIVED LOG 334 88.34 BACKUP PIECE 0 0 IMAGE COPY 0 0 FLASHBACK LOG 4 1.99 FOREIGN ARCHIVED LOG 0 0 7 rows selected. |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | [Primary-1] SQL> select file_type,number_of_files,percent_space_used from v$recovery_area_usage; FILE_TYPE NUMBER_OF_FILES PERCENT_SPACE_USED -------------------- --------------- ------------------ CONTROL FILE 0 0 REDO LOG 0 0 ARCHIVED LOG 339 22.17 BACKUP PIECE 0 0 IMAGE COPY 0 0 FLASHBACK LOG 0 0 FOREIGN ARCHIVED LOG 0 0 7 rows selected. |
Step8:
Change Standby Database Mode as Open.
1 2 3 4 5 6 7 8 9 10 11 | [Standby-1] SQL> alter database open; Database altered. SQL> select status from gv$instance; STATUS ------------ OPEN MOUNTED |
1 2 3 4 5 6 7 8 9 10 11 | [Standby-2] SQL> alter database open; Database altered. SQL> select status from gv$instance; STATUS ------------ OPEN OPEN |
Step9:
Check the Log Sequence numbers for both sides.
1 2 3 4 5 6 7 | [Primary-1-2 & Standby-1-2] SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#; MAX(SEQUENCE#) THREAD# -------------- ---------- 244 1 104 2 |
Step10:
Create a new table.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | [Standby-1] SQL> select table_name from dba_tables where owner='HR'; TABLE_NAME ------------------------------ JOB_HISTORY EMPLOYEES JOBS LOCATIONS REGIONS DEPARTMENTS COUNTRIES 7 rows selected. SQL> create table test.jobs_yedek as select * from hr.jobs; Table created. SQL> select count(*) from test.jobs_yedek; COUNT(*) ---------- 19 |
1 2 3 4 5 6 | [Standby-2] SQL> select count(*) from test.jobs_yedek; COUNT(*) ---------- 19 |
Step11:
On the primary side, perform log switch operation on each instance and to check whether Redo-Transport is working properly.
1 2 3 4 | [Primary-1] SQL> alter system switch logfile; System altered. |
1 2 3 4 | [Primary-2] SQL> alter system switch logfile; System altered. |
1 2 3 4 5 6 7 | [Primary-1-2 & Standby-1-2] SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#; MAX(SEQUENCE#) THREAD# -------------- ---------- 245 1 105 2 |
Convert Physical Standby to Snapshot Standby using Dgmgrl
Step1:
Check the Configuration.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | DGMGRL> show configuration Configuration - DRSolution Protection Mode: MaxPerformance Members: primary - Primary database prmyFS - Far sync instance physical - Physical standby database snapshot - Physical standby database logical - Logical standby database logical2 - Physical standby database Members Not Receiving Redo: physclFS - Far sync instance Fast-Start Failover: DISABLED Configuration Status: SUCCESS (status updated 49 seconds ago) |
Step2:
Convert Physical Standby to Snapshot Standby using dgmgrl.
1 2 3 | DGMGRL> convert database snapshot to snapshot standby; Converting database "snapshot" to a Snapshot Standby database, please wait... Database "snapshot" converted successfully |
Step3:
Check the configuration again.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | DGMGRL> show configuration Configuration - DRSolution Protection Mode: MaxPerformance Members: primary - Primary database prmyFS - Far sync instance physical - Physical standby database snapshot - Snapshot standby database logical - Logical standby database logical2 - Physical standby database Members Not Receiving Redo: physclFS - Far sync instance Fast-Start Failover: DISABLED Configuration Status: SUCCESS (status updated 49 seconds ago) |
Step4:
Check the Flashback status.
1 2 3 4 5 | [Snapshot - 07-04-2017 14:04:19] SQL> select flashback_on from v$database; FLASHBACK_ON ------------------ RESTORE POINT ONLY |
Step5:
Check the database role.
1 2 3 4 5 | [Snapshot - 07-04-2017 14:04:31] SQL> select open_mode, database_role from v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ WRITE SNAPSHOT STANDBY |
Sometimes, when it is checked from the Broker after this convert operation, the following warnings about the configuration can be received. A few minutes after these warnings, errors appear to solved on their own without any intervention from the DBA. The cause and solution of the error is below.
ORA-16778: redo transport error for one or more databases
Step1:
Convert Physical Standby to Snapshot Standby using dgmgrl.
1 2 3 | DGMGRL> convert database snapshot to snapshot standby; Converting database "snapshot" to a Snapshot Standby database, please wait... Database "snapshot" converted successfully |
Step2:
Check the configuration.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | DGMGRL> show configuration Configuration - DRSolution Protection Mode: MaxPerformance Members: primary - Primary database prmyFS - Far sync instance Error: ORA-16778: redo transport error for one or more databases physical - Physical standby database snapshot - Snapshot standby database logical - Logical standby database logical2 - Logical standby database Members Not Receiving Redo: physclFS - Far sync instance Fast-Start Failover: DISABLED Configuration Status: ERROR (status updated 25 seconds ago) |
Step3:
Check the archives’ status in Primary and Snapshot.
1 2 3 4 5 6 7 8 9 10 11 | [Primary - 10-04-2017 11:19:16] SQL> select max(sequence#) from v$archived_log group by thread#; MAX(SEQUENCE#) -------------- 869 [Snapshot - 10-04-2017 11:19:16] SQL> select max(sequence#),applied from v$archived_log group by thread#,applied; MAX(SEQUENCE#) APPLIED -------------- --------- 868 YES |
Step4:
Check if the logs are transferred to snapshot by performing the Log Switch.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | [Primary - 10-04-2017 11:19:18] SQL> alter system switch logfile; System altered. [Primary - 10-04-2017 11:19:58] SQL> select max(sequence#) from v$archived_log group by thread#; MAX(SEQUENCE#) -------------- 870 [Snapshot - 10-04-2017 11:19:36] SQL> / MAX(SEQUENCE#) APPLIED -------------- --------- 868 YES |
Note: We have seen that the logs are not transferred to the Snapshot database.
Step5:
Check RedoRoutes from Primary Far SYNC.
1 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 | DGMGRL> show far_sync 'prmyFS' redoroutes RedoRoutes = '(primary:physical,snapshot,logical,logical2 ASYNC)' DGMGRL> show configuration Configuration - DRSolution Protection Mode: MaxPerformance Members: primary - Primary database prmyFS - Far sync instance Error: ORA-16778: redo transport error for one or more databases physical - Physical standby database snapshot - Snapshot standby database Warning: ORA-16857: standby disconnected from redo source for longer than specified threshold logical - Logical standby database logical2 - Logical standby database Members Not Receiving Redo: physclFS - Far sync instance Fast-Start Failover: DISABLED Configuration Status: ERROR (status updated 35 seconds ago) |
There is no error related to Redo Transport. When the error is investigated, it is understood that it is caused by the “TransportDisconnectedThreshold” and “ReopenSecs” parameters.
TransportDisconnectedThreshold: Indicates that the last communication with the Primary has exceeded the specified threshold. After this exceed, Primary cannot send redos to this location. Default is 30 seconds.
ReopenSecs: If one of the destinations where the Redos will be sent fails, it determines how many seconds later it will try to send. It is 300 seconds in the default.
MaxFailure: It determine maxfailure count. If you set 3 , it tries 3 times to send redos even if it has failed. Default is 0. So it tries endless times.
1 2 3 4 5 6 7 8 9 10 11 12 13 | DGMGRL> show database primary TransportDisconnectedThreshold TransportDisconnectedThreshold = '30' DGMGRL> show database primary MaxFailure MaxFailure = '0' DGMGRL> show database primary ReopenSecs ReopenSecs = '300' DGMGRL> show far_sync 'prmyFS' TransportDisconnectedThreshold TransportDisconnectedThreshold = '30' DGMGRL> show far_sync 'prmyFS' MaxFailure MaxFailure = '0' DGMGRL> show far_sync 'prmyFS' ReopenSecs ReopenSecs = '300' |
Step7:
The ReopenSecs parameter is reduced to 30 seconds. After this parameter is set, sending logs is started.
In addition, the TransportDisconnectedThreshold parameter is set to 300 seconds so that no errors are received.
1 2 3 4 5 | DGMGRL> edit database snapshot set property 'ReopenSecs'=30; Property "ReopenSecs" updated DGMGRL> edit database snapshot set property TransportDisconnectedThreshold=300; Property "transportdisconnectedthreshold" updated |
Step8:
Check the configuration again.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | DGMGRL> show configuration Configuration - DRSolution Protection Mode: MaxPerformance Members: primary - Primary database prmyFS - Far sync instance physical - Physical standby database snapshot - Snapshot standby database logical - Logical standby database logical2 - Logical standby database Members Not Receiving Redo: physclFS - Far sync instance Fast-Start Failover: DISABLED Configuration Status: SUCCESS (status updated 7 seconds ago) |
Convert Snapshot Standby Back to Physical Standby
Step1:
Shut down all Snapshot Standby Instances
1 2 3 4 5 | [Standby-1-2] SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. |
Step2:
Start only the first Snapshot Standby Instance in mount mode.
1 2 3 4 5 6 7 8 9 | SQL> startup mount; ORACLE instance started. Total System Global Area 6480490496 bytes Fixed Size 2265384 bytes Variable Size 1241517784 bytes Database Buffers 5217714176 bytes Redo Buffers 18993152 bytes Database mounted. |
Step3:
Convert snapshot standby back to physical standby .
1 2 3 | SQL> alter database convert to physical standby; Database altered. |
The logs are as follows.
1 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 | [Standby-1] alter database convert to physical standby ALTER DATABASE CONVERT TO PHYSICAL STANDBY (primary1) Flashback Restore Start Flashback Restore Complete Drop guaranteed restore point Deleted Oracle managed file +FRA/standby/flashback/log_1.599.932481007 Deleted Oracle managed file +FRA/standby/flashback/log_2.600.932481007 Deleted Oracle managed file +FRA/standby/flashback/log_3.601.932481011 Deleted Oracle managed file +FRA/standby/flashback/log_4.602.932481013 Guaranteed restore point dropped Clearing standby activation ID 1769842254 (0x697da64e) The primary database controlfile was created using the 'MAXLOGFILES 192' clause. There is space for up to 188 standby redo logfiles Use the following SQL commands on the standby database to create standby redo logfiles that match the primary database: ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800; ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 52428800; Shutting down archive processes Archiving is disabled Thu Jan 05 15:40:40 2017 ARCH shutting down ARC7: Archival stopped Thu Jan 05 15:40:40 2017 ARCH shutting down ARC1: Archival stopped Thu Jan 05 15:40:40 2017 ARCH shutting down Thu Jan 05 15:40:40 2017 ARCH shutting down ARC3: Archival stopped ARC0: Archival stopped Thu Jan 05 15:40:40 2017 ARCH shutting down ARC2: Archival stopped Thu Jan 05 15:40:40 2017 ARCH shutting down ARC5: Archival stopped Thu Jan 05 15:40:40 2017 ARCH shutting down ARC6: Archival stopped Thu Jan 05 15:40:40 2017 ARCH shutting down ARC4: Archival stopped Completed: alter database convert to physical standby Thu Jan 05 15:40:47 2017 SUCCESS: diskgroup FRA was dismounted SUCCESS: diskgroup DATA was dismounted NOTE: Database dismounted; ASMB process exiting Stopping background process RBAL Stopping background process MARK Thu Jan 05 15:40:49 2017 NOTE: Shutting down MARK background process |
Step4:
Close Standby – 1 again and start in mount mode.
1 2 3 4 5 6 7 8 9 10 11 12 13 | SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 6480490496 bytes Fixed Size 2265384 bytes Variable Size 1241517784 bytes Database Buffers 5217714176 bytes Redo Buffers 18993152 bytes Database mounted. |
Step5:
Start Standby -2 in mount mode.
1 2 3 4 5 6 7 8 9 10 | [Standby-2] SQL> startup mount; ORACLE instance started. Total System Global Area 6480490496 bytes Fixed Size 2265384 bytes Variable Size 1241517784 bytes Database Buffers 5217714176 bytes Redo Buffers 18993152 bytes Database mounted. |
Step6:
If you will use Active Data Guard, open the databases.
1 2 3 4 | [Standby-1-2] SQL> alter database open read only; Database altered. |
Step7:
Check the existence of the table created when we convert it to Snapshot Standby.
1 2 3 4 5 6 | [Standby-1-2] SQL> select count(*) from test.jobs_yedek; select count(*) from test.jobs_yedek * ERROR at line 1: ORA-00942: table or view does not exist |
Step8:
Start recovery.
1 2 3 | SQL> alter database recover managed standby database using current logfile disconnect; Database altered. |
The logs are as follows.
1 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 | alter database recover managed standby database using current logfile disconnect Attempt to start background Managed Standby Recovery process (primary1) Thu Jan 05 15:58:54 2017 MRP0 started with pid=58, OS id=21657 MRP0: Background Managed Standby Recovery process started (primary1) started logmerger process Thu Jan 05 15:58:59 2017 Managed Standby Recovery starting Real Time Apply Thu Jan 05 15:59:00 2017 Reconfiguration started (old inc 4, new inc 6) List of instances: 1 2 (myinst: 1) Global Resource Directory frozen Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Thu Jan 05 15:59:00 2017 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Thu Jan 05 15:59:00 2017 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived Set master node info Submitted all remote-enqueue requests Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted Submitted all GCS remote-cache requests Fix write in gcs resources Reconfiguration complete Parallel Media Recovery started with 4 slaves Thu Jan 05 15:59:01 2017 CHANGE TRACKING found new resetlogs, resetting. old SCN: 0x0000.00215455, new SCN: 0x0000.000e2006 old time: 932481024, new time=932222810 CHANGE TRACKING is reinitializing the change tracking file. Starting background process CTWR Thu Jan 05 15:59:01 2017 CTWR started with pid=64, OS id=21692 Block change tracking service is active. Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Completed: alter database recover managed standby database using current logfile disconnect Clearing online redo logfile 1 +DATA/standby/onlinelog/group_1.263.932283679 Clearing online log 1 of thread 1 sequence number 249 Clearing online redo logfile 1 complete Clearing online redo logfile 3 +DATA/standby/onlinelog/group_3.265.932283681 Clearing online log 3 of thread 2 sequence number 109 Clearing online redo logfile 3 complete Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_2_seq_104.603.932481323 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_1_seq_244.604.932481381 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_2_seq_105.606.932481785 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_1_seq_245.605.932481781 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_1_seq_246.599.932486007 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_2_seq_106.600.932486007 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_2_seq_107.602.932486007 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_1_seq_247.601.932486007 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_2_seq_108.609.932486009 Media Recovery Log +FRA/standby/archivelog/2017_01_05/thread_1_seq_248.608.932486007 Media Recovery Waiting for thread 1 sequence 249 (in transit) Recovery of Online Redo Log: Thread 1 Group 5 Seq 249 Reading mem 0 Mem# 0: +DATA/standby/onlinelog/group_5.267.932283683 Mem# 1: +FRA/standby/onlinelog/group_5.260.932283683 Media Recovery Waiting for thread 2 sequence 109 (in transit) Recovery of Online Redo Log: Thread 2 Group 8 Seq 109 Reading mem 0 Mem# 0: +DATA/standby/onlinelog/group_8.270.932283685 Mem# 1: +FRA/standby/onlinelog/group_8.263.932283685 |
Step9:
Check for flashback logs and restore points.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | [Standby-1-2] SQL> select file_type,number_of_files,percent_space_used from v$recovery_area_usage; FILE_TYPE NUMBER_OF_FILES PERCENT_SPACE_USED -------------------- --------------- ------------------ CONTROL FILE 0 0 REDO LOG 0 0 ARCHIVED LOG 344 88.66 BACKUP PIECE 0 0 IMAGE COPY 0 0 FLASHBACK LOG 0 0 FOREIGN ARCHIVED LOG 0 0 7 rows selected. SQL> set linesize 500 SQL> column name format a50 SQL> select name, storage_size from v$restore_point; no rows selected |
