Tag Archives: Oracle

FGA, AUDIT_CONDITION, and SYS_CONTEXT

Recently Flora tweeted to her blog post about a conditional audit for Fine Grant Audit (FGA) and questioned “Who on earth is doing that ?!”, and I remembered that I made something similar at my previous job. So, here a little glimpse of how to use the FGA, AUDIT_CONDITION, and SYS_CONTEXT to conditionally decide if you audit or no.

So, at my previous job, years ago (while still using 11g), I received these requests: “We need to audit everything that does not come from the application”, and more, “the audit needs to have the small overhead possible”.

And to explain the context why these are important, the system was used to control the judicial processes (court of justice) and the database handles more the 1 million of IOPS (the reason for the small needed overhead). And since is a sensible area, the system itself if heavily audited (application have own audit system), so we don’t need to audit the app – but everything else.

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 4 – 19.7 to 19.8

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version.

The fourth part covers the upgrade from 19.7 to 19.8. I separate so you can use this as a direct guide from 19.6 to 19.7 if you need to do just this update. Parts of this post are similar to the upgrade from 19.6 to 19.7 that I described in the previous post.

Patch Matrix

The matrix of what can be done can be found at this post from ODA blog, and you can check below:

Another important detail is to check the MOS note ODA: Quick Reference Matrix for Linux Release and Kernel by ODA Hardware Type and Version (Doc ID 2680219.1) and verify if your hardware is still compatible.

Remember that in this process, the ODA will reboot several times, so, you need to inform your teams that databases will be unavailable during the process.

Click here to read more…

ZDLRA + MAA, Protection for Gold Architecture

The Gold architecture for MAA is used to emphasis the application continuity. All the possible outages (planned or no) are protected by Oracle features. Here we are one step further and start to design using multi-site architecture. Data Guard, RAC, Oracle Clusterware, everything is there. But even with these, ZDLRA is still needed to allow complete protection.

The image above taken from https://www.oracle.com/a/tech/docs/maa-overview-onpremise-2019.pdf.

With the MAA references, we have the blueprints and highlights how to protect them since the standalone/single instance until the multiple site database. But for Gold we are beyond RPO and RTO, they are important but application continuity and data continuity join to complete the whole picture.

Click here to read more…

ZDLRA + MAA, Protection for Silver Architecture

The MAA defined Silver architecture for database environments that use (or need) high availability to survive for outages. The idea is having more than one single instance running, and to do that, it relies on Oracle Clusterware and Engineered Systems to mitigate the single point of failure. But is not just a database that gains with this, the Silver architecture is the first step to have application continuity. And again, ZDLRA is there since the beginning.

As you can see above, the Silver by MAA blueprints improves compared with Bronze architecture that I spoke at the last post. But the basic points are there: RPO and RTO. They continue to base rule here. And the goals are the same: Data Availability, Data Protection, Performance (no impact), Cost (lower cost), and Risk (reduce). More technical details here at the MAA Overview doc.

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 3 – 19.6 to 19.7

This is the third part of the ODA patch series, from 18.3 to 19.8. I separate in multiple parts and you can use this part as a direct guide to patch ODA from 19.6 to 19.7. Each part can be used alone since they cover all the needed steps. Some steps of this post are similar to the upgrade from 18.8 to 19.6 that I described in the previous post.

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version. 

Click here to read more…

ZDLRA + MAA, Protection for Bronze Architecture

Oracle Maximum Availability Architecture (MAA) means more than just Data Guard or Golden Gate to survive outages, is related to data protection, data availability, and application continuity. MAA defines four reference architectures that can be used to guide during the deploy/design of your environment, and ZDLRA is there for all architectures.

Image above taken from https://www.oracle.com/a/tech/docs/maa-overview-onpremise-2019.pdf.

With the MAA references, we have the blueprints and highlights how to protect them since the standalone/single instance until the multiple site database. The MAA goal is to survive an outage but also sustain: Data Availability, Data Protection, Performance (no impact), Cost (lower cost), and Risk (reduce).

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 2 – 18.8 to 19.6

This is the second part of the ODA patch series, from 18.3 to 19.8. I separate in multiple parts and you can use this second as a direct guide to patch ODA from 18.8 to 19.6. Each part can be used alone since they cover all the needed steps. Parts of this post are similar to the upgrade from 18.3 to 18,8 that I described in my previous post.

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version.

Click here to read more…

Patch ODA from 18.3 to 19.8. Part 1 – 18.3 to 18.8

The process of patch ODA is not complicated but requires attention over some steps. The 19.6 version was the first that was possible to patch from 18.8 version, and the version that allows upgrades to newer. If you want to go directly to 19.5 you need to reimage of the appliance. In this post, I will cover the process that I made recently to patch from 18.3 to 19.8 version.

The first part covers the upgrade from 18.3 to 18.8.

Patch Matrix

The matrix of what can be done can be found at this post from ODA blog, and you can check below:

Another important detail is to check the MOS note ODA: Quick Reference Matrix for Linux Release and Kernel by ODA Hardware Type and Version (Doc ID 2680219.1) and verify if your hardware is still compatible.

Remember that in this process, the ODA will reboot several times, so, you need to inform your teams that databases will be unavailable during the process.

Click here to read more…

ZDLRA, How to Maintain the Native Replication

The native replication for ZDLRA does not require a lot of maintenance or complicate tasks to keep it running. In my previous posts, I already wrote about an explanation about replication, how to configure the replication network between ZDLRA’s, how to configure the replication server, how to create the replication config (that links everything is done before), and how the replication protect the database. In this post, I will show some details that you need to monitor and to do maintain it running without errors.

Click here to read more…

ZDLRA, Protecting Databases with Replication

The replication for ZDLRA works differently than normal DataGuard, but you can reach almost the same level of multiple site protection with that. The replication for ZDLRA is not complicated but can be divided into several steps. Basically, to protect a database (since you have everything configure) is done linking the database with the protection policy that is replicated.

In my previous posts, I already wrote about all the steps to reach this configuration. Starting with an explanation about replication, how to configure the replication network between ZDLRA’s, how to configure the replication server,  and how to create the replication config (that links everything is done before).

But most of the time we don’t need to pass through all of these steps. Usually, the ZDLRA is deployed with the replication network already configured, or you already deploy two ZDLRA’s that will operate replicated. This part I consider the “physical” part of the configuration because evolves network and details that we usually don’t touch after configured. The “logical” part comes after and evolves all the definitions about what policies will be replicated, which databases will be part of each policy, and so on. This “logical” configuration I explained in this previous post.

But it is important to know how it’s working to understand all the details. And if you need, you can check my posts about the replication for ZDLRA.

In this post, I will show more details on how the ZDLRA replication impact over the backup for your database, and show the protection occurs to reduce your RPO to a minimum.

Click here to read more…