How to disable and enable logshipping when your standby database is in maximum availabilty through DataGuard Broker Architecture.

   We may not be able to disable the logtransport when the database is in maximum availabilty mode. We may get the below error




DGMGRL> edit database 'DBNAME' set state=TRANSPORT-OFF;

Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode
 We may need to transfer the mode to maximum performance and disable the log transport.
Disable Logshipping
   1.1. Connect to dgmgrl broker
            dgmgrl
                 connect /
  1.2  Verify the protection mode
  DGMGRL> show configuration
 Configuration - DBNAME
   Protection Mode: MaxAvailability
   Databases:
     DBNAME    - Primary database
     DBNAME_SB - Physical standby database
 Fast-Start Failover: DISABLED
 Configuration Status:
 SUCCESS
 1.3 Disable the log apply in standby database
    EDIT DATABASE 'DBNAME_SB' SET STATE='APPLY-OFF';  
 1.4 Convert the database into maximum performance mode
   EDIT CONFIGURATION SET PROTECTION MODE AS MAXPERFORMANCE;
    
  1.5  Verify the configutaion
 DGMGRL> show configuration
 Configuration - DBNAME
   Protection Mode: MaxPerformance
   Databases:
     DBNAME    - Primary database
     DBNAME_SB - Physical standby database
 Fast-Start Failover: DISABLED
 Configuration Status:
 SUCCESS
 1.6  Disable to the log transport
      edit database 'DBNAME' set state='LOG-TRANSPORT-OFF';
 1.7 Verify the configuration in verbose mode
       show database verbose 'DBNAME'
      Database - DBNAME
   Role:            PRIMARY
   Intended State:  TRANSPORT-OFF
   Instance(s):
    .....
Enable Logshipping
 1.1 EDIT DATABASE 'DBNAME_SB' SET STATE='APPLY-ON';
 1.2 EDIT DATABASE 'DBNAME'  SET STATE='TRANSPORT-ON';
 1.3 EDIT CONFIGURATION SET PROTECTION MODE AS  'MAXAVAILABILITY'

   

Fast Mirror resync and Fast Rebalance - 11g new feature

1. Fast Mirror resync and Fast Rebalance - 11g new feature
     Fast Mirror resync and Fast Rebalance two new features available in 11g .

 Fast Mirror resync:

  ASM fast resync keeps track of pending changes to extents on an OFFLINE disk during an outage. The extents are resynced when the disk is brought back online or replaced.

By default, ASM drops a disk shortly after it is taken offline. You can set the DISK_REPAIR_TIME attribute to prevent this operation by specifying a time interval to repair the disk and bring it back online.

To use this feature, the disk group compatibility attributes must be set to 11.1 or higher
Fast Rebalance

In 11g, you can use the STARTUP RESTRICT command to control access to an ASM instance while you perform maintenance. This startup option is used to implement ASM Fast Rebalance feature. Rebalance operations that occur while a disk group is in RESTRICTED mode eliminate the lock and unlock extent map messaging between ASM instances in Oracle RAC environments.

When an ASM instance is started with 'STARTUP RESTRICT' option and is active in this mode, all of the disk groups are mounted in RESTRICTED mode which prevents databases from connecting to the ASM instance. In addition, the restricted clause of the ALTER SYSTEM statement is disabled for the ASM instance.
  Follow the below steps to do the fast rebalance
  1. startup restrict;
  2.  alter diskgroup dg1 mount restricted;
            ( we cannot mount the disk in mount mode and may get ORA-15251: only restricted mount is allowed in the ASM instance )

3.alter diskgroup dg1 rebalance;
  ( we cannot open database against the asm when it is in restrict mode,we may get the below error

ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '+DG1/11g/datafile/exy.256.627345731'

4.shutdown immediate
   ( we cannot enable restriced mode as we do in normal rdbms
     we may the below error
ORA-15000: command disallowed by current instance type
)

5.startup


2. How to improve rebalance operation when multiple disk maintenance activities are there and monitor the status of it.

  if you have multiple diskgroup managment commands like add disk /drop disks. It is recomended to run as a single command to have single rebalance operations rather than running the commands multiple times and invoke rebalances operations

  alter diskgroup diskgroup_name add disk '..../ drop disk '...' ;

Montior the sttaus of the asm operations using v$asm_operations view


SQL> desc v$asm_operation
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 GROUP_NUMBER                                       NUMBER
 OPERATION                                          CHAR(5)
 STATE                                              VARCHAR2(4)
 POWER                                              NUMBER
 ACTUAL                                             NUMBER
 SOFAR                                              NUMBER
 EST_WORK                                           NUMBER
 EST_RATE                                           NUMBER
 EST_MINUTES                                        NUMBER
 ERROR_CODE                                         VARCHAR2(44)

State of the operation:
WAIT - No operations running for the group
RUN - Operation running for the group
REAP - Operation is being run down
HALT - Operation halted by admin
ERRORS - Operation halted by errors

select state,ACTUAL ,sofar,EST_MINUTES ,operations from v$asm_operation

Speed-up expdp/impdp

 
1)Identify known issues/bugs and apply the required patches pro-actively on the souce & target servers
Checklist For Slow Performance Of DataPump Export (expdp) And Import (impdp) (Doc ID 453895.1)








2) Establish a dedicate connection between source and Target servers ( if feasible)
2.1. Avoid public network to transfer the data
        Open dedicated bandwidth between the source & Target server ( ip-ip copy: to speed up the copy over High Bandwidth card ) 

2.2.     Listener to be created on this network

2.3.     Create a DBLINK between source and target using this  network
2.4.     Do network based exp/imp
2.5      Don't copy LOB using network copy
ref: Performance Problems When Transferring LOBs Using IMPDP With NETWORK_LINK (Doc ID 1488229.1)








3)  Unload data only. Once data is unloaded, Later create indexes, constraints( enable novalidate if you are sure data is intact)
  ( Please let IMPDP create the partitioned table Ref: Slow DataPump Import (Impdp) Performance using Parallel Option with Pre-created Partitioned Tables (Doc ID 2098931.1))








4) In-case if you have RAC, Try to avail parallelism by running parallel exp/imp from different instances.







5) split into Multiple jobs

  5.1) Large tables can be typically exported or imported individually and smaller tables were grouped together into several batches with parallel options.







6) Table with LOB columns
   6.1) Isolate the BIG LOB tables ( don't club it together with the other small tables )
   6.1) Enable CACHE to improvise the import performance.
   6.2) Logically split the tables into multiple exp/imp jobs based on application logic using primary key or unique key.
   6.3 use DATA_OPTIONS=DISABLE_APPEND_HINT to avoid TM lock while doing multiple
import on the same lob table.
  6.4) Avoid Network COPY for LOB
  Ref: Performance Problems When Transferring LOBs Using IMPDP With NETWORK_LINK (Doc ID 1488229.1)







7) In-case if you want to use multiple imp on the same table
   7.1) use DATA_OPTIONS=DISABLE_APPEND_HINT to avoid TM lock while doing multiple import on the same lob table.





8) Undocumented parameters
    _disable_logging ( skip redo generation, it is very dangerous command , in-case if instance crash, data may get corrupted, end up doing reimport again)






9) estimate enough PGA for  creating indexes or enabling constraint at end of data unloading.