Oracle DBA

Oracle Data Guard Oracle Data Guard Oracle Data Guard is Oracle’s solution for high availability, data protection, and disaster recovery for enterprise databases. It creates and maintains one or more standby databases as transactionally consistent copies of a primary database. If the primary database becomes unavailable due to planned maintenance or unplanned outage, Data Guard can quickly switch a standby into the primary role, minimizing downtime. Data Guard services: Redo Transport Services and Apply Services , which handle shipping of redo logs and applying changes to standbys, as well as Role Transition services to switch roles between primary and standby. Redo Transport Services Control how redo is sent from primary to standbys (synchronously or asynchronously, how it’s buffered, etc.). Transport services also handle networking faults by queuing redo and resolving gaps if a standby missed some logs (e.g., netw...

RPO and RTO in Oracle Data Guard 1. Recovery Point Objective (RPO) What it is: RPO is about how much data loss you can tolerate if your primary database crashes. More precisely, it’s the maximum acceptable amount of time between your last backup (or last synchronized data) and the failure. In Oracle Data Guard terms: RPO means how far behind your standby database can lag before it’s no longer acceptable. It’s the "point in time" to which you can recover data after a failure. Example: Suppose you set your RPO as 5 minutes . If the primary database crashes, you accept that you might lose up to 5 minutes of data changes. Your standby must be kept synchronized enough so that, in case of failover, it won’t be more than 5 minutes behind the primary. 2. Recovery Time Objective (RTO) What it is: RTO is the maximum acceptable time to restore the database and get it up and running after a failure. In Oracle Data Guard terms: It’s the time between the failure ...

GC Buffer Busy Wait Fix in Oracle RAC Here’s the thing with gc buffer busy wait in Oracle RAC — it usually points to contention on data blocks that are being shared across RAC nodes. When one instance is holding a block in a mode another instance needs, the second waits, causing this event to spike. Let’s break down how to fix it: Identify the hot block or object causing contention Run a query on v$session_wait or gv$session_wait to see which objects or blocks are involved. Often, it’s a segment or index that many sessions hit simultaneously. Check the type of contention Is it on data blocks (DML), index blocks, or undo segments? That guides your action. Common fixes: Application tuning : Are many sessions updating the same rows or blocks? Try to spread the workload to reduce "hot spots." For example, avoid sequences that generate contention on the same block, or tune application logic to avoid frequent updates ...