In part 1, we have set forth the best practices that you should observe when setting up your Oracle Databases. Let us continue with the best practices for your Oracle systems.
Best practices for configuring Real Application Clusters
When dealing with Real Application Clusters, you should:
- Register all instances with remote listeners. Your listeners should be registered via the REMOTE_LISTENER parameter. This is to make sure that all of your listeners are aware of all the services and instances that run these services. What’s more, listeners should be utilizing server side load balancing. If you are using virtual IP addresses or cluster aliases, your listeners should be listening on this as well. One thing that listeners should avoid is listening in on the hostname, which would cause you to have disconnected sessions when the virtual IPs are automatically relocated to their owning nodes.
- Avoid setting up CLUSTER_INTERCONNECTS unless you need it to scale. CLUSTER_INTERCONNECTS is an initialization parameter that you only need to set up if there are two or more cluster interconnect and the default is not at par with the throughput requirements of the Real Application Clusters database.
Best practices for configuring Data Guard
After you have determined the right standby database for your needs, you should configure it right. The best practices to do this include:
- Making sure that there is a simple yet robust archiving configuration and strategy
- Using multiplexed standby redo logs with enough size
- Using FORCE LOGGING and Real Time Apply
- Setting up Dynamic Service Registration for your database and listeners
- Tuning the WAN network
- Doing a performance assessment for your planned network configuration
- Setting the Data Protection Mode
- Using a MAN or LAN for maximum protection or availability modes
- Using ARCH for the maximum performance throughput
- Using ASYNC to avoid loss of data
- Evaluating your SSH port forwarding
- Setting your LOG_ARCHIVE_LOCAL_FIRST to TRUE
- Make sure that redo data is securely transmitted
- Setting DB_UNIQUE_NAME and LOG_ARCHIVE_CONFIG
Best practices for configuring Oracle Maximum Availability Architecture (MAA)
To configure your MAA right, you should:
- Set up multiple standby instances. Having multiple standby instances and having multiple standby databases are two different things. Standby instances can have either managed recovery process or logical standby apply process, and all the other standby instances are designated as secondary. These multiple standby instances help you have transparent connection failover when things fail to connect to your primary standby instance. It also helps you do scheduled maintenance by allowing the secondary standby instances take over the host and the primary standby instance when you need to take them offline.
- Set up Connect-Time Failover for Network Service Descriptors. Connect-time failover happens when a connection request is redirected to another listener after the first request for connection fails.
Four Cornerstone can help you set up your Oracle Maximum Availability Architecture, Real Application Clusters and Data Guard with all these best practices in place. Call us at 817-377-1144 and start working with a team of certified Oracle experts, all of which have years of experience working in a variety of industries and working with different companies. We can also help you set up your backup and recovery systems as well as ensure fast application failovers.
Contact us now!
Photo courtesy of David Feng.
