DBA

https://docs.google.com/document/d/16jLzBuLu6gTBN7UpL51oXp3rKgvZWZfzyMY0rhdv4i4/edit?hl=en Using RMAN Incremental Backups to Roll Forward a Physical Standby Database   Case Details: Suppose network is down between primary server and standby server or standby server is down due to some hardware failure for long time.   In between down time, you have remove archive log file from primary server without taking backup of archive log files.   In above scenario, how to synchronies your standby database without archive logs.   Solution: We can use RMAN incremental backups to synchronize a physical standby database with the primary database. Using the RMAN BACKUP INCREMENTAL FROM SCN command, we can create a backup on the primary database that starts at the standby database’s current SCN, which can then be used to roll the standby database forward in time.   Step 1 On the standby database, stop the managed recovery process (MRP):   SQL> ALTER

The following scripts show how to turn on and enable standby database features, it's for 11gr2 database 1. convert standby database to snapshot standby and convert it back to physical standby. --To turn on snapshot read-write database SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SELECT flashback_on FROM v$database; --FLASHBACK_ON ------------------ --NO ALTER DATABASE CONVERT TO SNAPSHOT STANDBY; ALTER DATABASE OPEN; SELECT flashback_on FROM v$database; --FLASHBACK_ON ------------------ --RESTORE POINT ONLY --To flashback database and resume standby SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SHUTDOWN IMMEDIATE; STARTUP NOMOUNT; ALTER DATABASE MOUNT STANDBY DATABASE; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; SELECT flashback_on FROM v$database; --FLASHBACK_ON ------------------ --NO 2. Read Only standby SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:18183400346178753 from Arup Nanda Most V$ views work by selecting information from the corresponding GV$ view with a predicate "where instance_id = <that instance>". So V$SESSION in Instance 1 is actually "SELECT * FROM GV$INSTANCE WHERE INST_ID = 1". On a three node RAC database, if you select from v$session, you get sessions from that instance only. Selecting from GV$SESSION creates parallel query slaves on the other instances and gets the information back to your session.  This works fine in almost all cases. There are few exceptions: in case of redo logs, the RAC instance must see all the redo logs of other instances as they become important for its recovery. Therefore, V$LOG actually shows all the redo logs, of all the instances, not just of its own. Contrast this with V$SESSION, which shows only sessions of that instance, not all. So, if there are 3 log file groups per instance (