OraEasy

Introduction Snapshot Standby is a feature available since Oracle 11g that lets you perform read-write operations on a standby database. Suppose your application team wants to test against fresh, live production-like data, but you can't let them run tests directly on the primary. Converting the physical standby into a snapshot standby solves this: the application team gets a fully read-write copy of production data to work with, while the actual primary stays untouched. Once testing wraps up and the standby converts back to physical, all the changes made during the snapshot window are automatically rolled back, and the standby resumes catching up with the primary as if nothing happened. While a database is in snapshot standby mode, Primary database changes are not applied to it, since no MRP process runs during this window. Prerequisites Oracle Data Guard should already be configured. Disable Data Guard Broker if it's in use, since Broker would automatically restart MRP...

Introduction A Release Update (RU) is Oracle's primary method for delivering both bug fixes and new features for Oracle Database versions 12.2 and later. Introduced to replace the older Patch Set Updates (PSUs) and Critical Patch Updates (CPUs), RUs are part of Oracle's shift toward a more predictable and modern patching model. In this article, we'll apply the Oracle RU 19.27 patch to both a primary and a standby database. Data Guard Standby-First Patch Apply Since Data Guard is configured, Oracle's standard recommendation is to apply the patch to the standby database first. Before doing so, always check the patch ReadMe to confirm the patch is Data Guard Standby-First Installable , not every patch supports this. See Oracle Doc 1265700.1 for details on this requirement. Approach Apply the patch at the binary level on the standby. Apply the patch at the binary level on the primary. Confirm primary and standby are back in sync. Run datapatch (the SQL-level pa...

Introduction Since Oracle 12c, the CDB (Container Database) and PDB (Pluggable Database) model has been the recommended architecture, and the non-CDB architecture is deprecated and unsupported starting from Oracle 21c. In an earlier article , we covered migrating a non-CDB into a CDB using the DBMS_PDB plugging method, which requires taking an RMAN backup, restoring it as a standalone instance, and then plugging that in. This article covers a second approach, creating the PDB directly over a database link, which skips the RMAN restore step entirely and pulls the non-CDB's data straight across the network in one CREATE PLUGGABLE DATABASE command. Patch Consideration If the source and destination aren't at the same patch level, you'll see PDB violations in the PDB_PLUG_IN_VIOLATIONS view, exactly as with the plugging method. The resolution depends on direction: If the destination is at a higher patch level than the source, run datapatch -verbose on the destination ...