A client ran into a recovery scenario recently that made me realize that some of the simpler scenarios are often forgotten. So this is a quick post just as a reminder some recovery scenarios can be easy. And it emphasizes how Oracle works to ensure that recovery is quick and painless.
Viewing entries tagged
Oracle Databases
Oracle 12c introduced a new utility which replaces the need to run post installation SQL scripts after a database patch is applied.
This new utility is called “Datapatch” and it is shipped with 12c binaries as a component of OPatch distribution.
“Datapatch” is very useful in multitenant environments where multiple PDBs (Pluggable Databases) must be patched together.
With the release of Database 12.1.0.2, Oracle introduced a new functionality oriented to exchange information in JavaScript Object Notation (JSON) data format between applications and the database engine.
JSON is a language-independent data format based on the JavaScript Programming Language often used for exchanging structured data between heterogeneous web applications.
JSON database implementation allows you store and retrieve data between the applications and the database engine conforming to the JSON standard avoiding the need of writing custom procedures and special code.
With every new version, Oracle introduces exciting features like Oracle Multitenant option, Oracle Active Data Guard Far Sync, information lifecycle management enhancements and new data types just to name a few. Customers wishing to take advantage of these and other new features will need to upgrade their existing databases, as well as migrate onto modern infrastructure to ensure high levels of performance.
The purpose of this blog is to show how different performance strategies can be implemented using the Oracle Database Resource Manager. Some practical examples are looked at to illustrate the point.
Resource Manager is designed to maximize throughput, so the resource plan directive given is no hard limit. In a CPU constrained system, we can allocate more CPU resources to OLTP users than to batch-jobs. With Resource Manager, the DBA can plan for a more proactive and predictable performance perspective – meeting service level agreements.