Posts

Showing posts from April, 2019

A failover is typically used only when the Oracle primary database becomes unavailable

A failover is typically used only when the primary database becomes unavailable, and there is no possibility of restoring it to service within a reasonable period of time Performing a Failover to a Physical Standby Database – Step 01- Flush any unsent redo from the primary database to the target standby database If the primary database can be mounted, it may be possible to flush any unsent archived and current redo from the primary database to the standby database. If this operation is successful, a zero data loss failover is possible even if the primary database is not in a zero data loss data protection mode. Mount, but do not open primary database. If primary database cannot be mounted go to step 2. On Primary database ( if accessible during real disaster ) SQL> ALTER SYSTEM FLUSH REDO TO target_db_name; For target_db_name, specify the DB_UNIQUE_NAME of the standby database that is to receive the redo flushed from the primary database. This statement flushes any unsent...

performed Switchover and Switchback in Oracle 12c

12c Data guard Switchover Best Practices using SQLPLUS (Doc ID 1578787.1 Performed Switchover and Switchback  in Oracle 12c 2 instances Oracle 12c RAC primary database ( TSTDB) Single instance Oracle 12c RAC Standby database ( TSTSBY) Noted – all the issues – documented steps Switchover and Switchback in 12c 1.       Ensure log_archive_dest_2 is configured on PRIMARY and STANDBY databases 2.       Media Recovery Process (MRP) is active on STANDBY and in sync with PRIMARY database 3.       Create STANDBY REDO logs on PRIMARY, if not exists 4.       FAL_CLIENT & FAL_SERVER parameters set on both databases    Pre-Switchover in 12c oracle@raj1 (SID:TSTDB_1) /h01/app/oracle/db/12.1.0.2_03/dbs $ srvctl status database -d TSTDB Instance TSTDB_1 is running on node raj1 Instance TSTDB_2 is running on node raj2 DGMGRL> connect / Connected as SYSDG. DGMGRL> show...

OEM 13c Blackout Stuck in 'Stop Pending' Status

issue was started due to two blackout were created DR databases  stopped the Blackout job manually OEM Blackout was hug state  Workaround fix the problem  Solution  create  balackout for the DR database again for 10 minutes - wait to end blackout automatically    all good now 

SWITCHOVER ERROR: Switchover target couldn't convert to primary database due to error 1275

alter database switchover to TSTSBY Mon Apr 08 12:04:40 2019 Starting switchover [Process ID: 19008] Mon Apr 08 12:04:40 2019 SWITCHOVER ERROR: Switchover target couldn't convert to  primary database due to error 1275. Check switchover target's alert log for detailed error. USER (ospid: 19008): terminating the instance Mon Apr 08 12:05:53 2019 Instance terminated by USER, pid = 19008 ORA-16471 signalled during: alter database switchover to TSTSBY. SQL> SELECT database_role role, name,dbid, db_unique_name, platform_id, open_mode, log_mode, flashback_on, protection_mode, protection_level FROM v$database; ROLE             NAME            DBID DB_UNIQUE_NAME                 PLATFORM_ID ---------------- --------- ---------- ------------------------------ ----------- OPEN_MODE            LOG_MODE  ...

Oracle Standby database

Shutting Down a Physical Standby Database Issue the following query to find out if the standby database is performing Redo Apply or real-time apply.  If the MRP0 or MRP process exists, then the standby database is applying redo. SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY; If Redo Apply is running, cancel it as shown in the following example: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; Shut down the standby database. SQL> SHUTDOWN IMMEDIATE; Start and mount the physical standby database: SQL> STARTUP MOUNT; Start Redo Apply or real-time apply: To start Redo Apply, issue the following statement: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  DISCONNECT FROM SESSION; To start real-time apply, issue the following statement: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  USING CURRENT LOGFILE; ALTER SESSION SET nls_date_format=’DD-MON-YYYY HH24:MI:SS’; select ...

explan plan

select * from table(dbms_xplan.display_cursor('2hbdag3dfzj9u')); select * from table(dbms_xplan.display_cursor('sqlid')); -- For more details and generally excellent report (11g only) set pagesize 0 echo off timing off linesize 1000 trimspool on trim on long 2000000 longchunksize 2000000 select DBMS_SQLTUNE.REPORT_SQL_MONITOR('sqlid') from dual;