More Related Content
What's hot (20)
Similar to Oracle Data Guard Physical Standby Configuration (20)
More from Arun Sharma (20)
Recently uploaded (20)
![Download Wondershare Filmora Crack [2025] With Latest](https://cdn.slidesharecdn.com/ss_thumbnails/neo4j-howkgsareshapingthefutureofgenerativeaiatawssummitlondonapril2024-240426125209-2d9db05d-250419-250428115407-a04afffa-thumbnail.jpg?width=560&fit=bounds)
Oracle Data Guard Physical Standby Configuration
- 3. Standby details Assumption: we assume that primary server has a database (SID=ip7) up and running. The standby database has Oracle 12cR2 installation done in the same oracle home location as primary.
- 4. Primary database changes Primary must run in archive log mode. Check the archive log mode
- 5. If it is not running in archive log mode, then enable it Enable force logging on primary: In oracle, users can restrict redo generation for SQL by using NOLOGGING clause. This NOLOGGING transaction will be a problem for physical standby. Hence, we force logging so even user uses NOLOGGING clause, every SQL will be logged on to redo
- 6. Standby file management: We need to make sure whenever we add/drop datafile in primary database, those files are also added / dropped on standby Create standby log files: You must create standby log files on primary. These files are used by a standby database to store redo it receives from primary database.
- 7. Our primary may become standby later and we would need them, so better to create it. First check the current log groups:
- 8. Add the standby logfiles, make sure group number should be from a different series like in this case we choose to start with 11 and above. This helps in easy differentiation. Make sure to keep the thread# and logfile size exactly same. Oracle also recommends to always create n+1 standby log files. Where n is the total number of logfiles
- 9. Check the standby log files via below query Enable flashback on primary: Flashback database is highly recommended because in case of failover, you need not re- create primary database from scratch
- 10. If flashback parameters are not set properly, use below commands
- 11. Check DB Unique name parameter on primary: Make sure your primary database has DB_UNIQUE_NAME parameter set for consistency. If it’s not set properly, use ALTER SYSTEM SET command
- 12. Create password file for standby: This is needed for cloning purpose. Even if there is one password file in $ORACLE_HOME/dbs location, create a new one with standby SID
- 13. Configure network Use below tns entries and put them under ORACLE user HOME/network/admin/tnsnames.ora. Change host as per your environment and execute on both primary and standby. Notice the use of the SID, rather than the SERVICE_NAME in the entries. This is important as the broker will need to connect to the databases when they are down, so the services will not be present.
- 15. Configure listener on primary database. Since the broker will need to connect to the database when it’s down, we can’t rely on auto-registration with the listener, hence the explicit entry for the database.
- 16. Configure listener on standby. Since the broker will need to connect to the database when it’s down, we can’t rely on auto-registration with the listener, hence the explicit entry for the database.
- 17. Once the listener.ora changes are in place, restart the listener on both servers
- 18. Configure redo transport Note: if you plan to use Oracle Data Guard broker, then you can skip this section “configure redo transport” and jump to “Build Standby” section.
- 19. Configure redo transport from primary to standby: The below statement says that if the current database is in primary role, then transport logs to standby. We need to change service and db_unique_name for same parameter on standby server
- 20. Setup FAL (Fetch Archive Log) server: This parameters tell the primary as to where it will get archives from (FAL Server=proddb_st) Setup Data Guard configuration on primary: This parameter will let primary database know which databases are in data guard configuration.
- 21. Build standby On standby server, create parameter file with below contents
- 22. Create pfile on primary, open it and create the necessary directories on the standby server
- 23. Start the auxiliary instance on the standby server by starting it using the temporary “init.ora” file
- 24. Duplicate primary database via RMAN: In this step, we will use RMAN to duplicate primary database for our standby database. On primary, connect to RMAN, specifying a full connect string for both the TARGET and AUXILIARY instances. Do not attempt to use OS authentication or the database cloning will fail
- 25. Once cloning is done, you should see below at RMAN prompt. Set Standby Parameters: We need to make some changes to standby parameters that will enable log shipping to the current primary (ip7) when a switchover happens
- 26. Once cloning is done, you should see below at RMAN prompt. Set Standby Parameters: We need to make some changes to standby parameters that will enable log shipping to the current primary (ip7) when a switchover happens
- 28. Now re-create spfile for standby using the pfile you just modified Enable flashback on standby: As we know the importance of flashback in data guard, we must enable it on standby as well
- 29. Verify standby configuration Once MRP is started, we must verify if our setup is working fine
- 31. Configure Archive deletion policy: We must set this policy in order to prevent accidental deletion of archive logs on primary database
- 32. Courses | Projects | Bootcamps