Configuring Oracle AFD after Installation

Configuring Oracle AFD After Installation

Configuring Oracle AFD after Installation

 

Purpose of this post is to investigate on configuring Oracle AFD after Installation. for more information regarding Oracle AFD fundamentals and migrating to Oracle ASMLIB From AFD please visit links below:

Introducing  Oracle AFD

Migrating to Oracle ASMLIB From AFD

Let me show you how to configure Oracle AFD after Installation within a scenario:

Existing setup:

Before start configuring Oracle AFD after Installation we check existing setup:

start configuring Oracle AFD

As you saw in preceding codes, ASMLIB used for accessing ASM Disks and the Clusterware stack is up. In the next step, we have to add Oracle AFD access path to ASM disk strings. If we do not specify the correct path, the Clusterware stack will not come up.

Oracle AFD access path published globally in Clusterware stack, (the globally means that the configuration is propagated in many areas like OCR, ASM spfile or gpnp profile). To start the creation of Oracle AFD disks, we require root user permission and Clusterware stack needs to be down. As I mentioned in the introducing Oracle AFD, ASMLIB and Oracle AFD are mutually exclusive. Thus I am going to stop and disable ASMLIB and then create Oracle AFD disks.

Let me check the correctness of Oracle AFD installation and configuration.

Preceding codes verified the correctness of installation and configuration of Oracle AFD. As you saw labels and references do exist in Oracle AFD path. Be aware of an important point, we have to disable oracleasm service in the OS, otherwise, the Clusterware stack will not come up correctly.

You could find more information about Oracle AFD in MOS.

Bring Clusterware back up

Verification:

As I expected, Clusterware came up again correctly. As I love tidy works, let’s clean up disk strings and do some verification.

Observing Oracle AFD behaviour

Undoubtedly, Oracle AFD has many advantages over ASMLIB. The most impressive feature is rejecting non-Oracle I/Os, which prevents AFD disks from corruption. In upcoming codes, I am going to simulate intentional non-Oracle disks manipulation and we will observe Oracle AFD behaviour.

In preceding codes, grid user received the permission denied because it has no direct access to block devices to manipulate Oracle AFD disks.

Although it seems that the root user could change disks but it is not true. Let’s take a look at /var/log/messages

In the above appearance, we could see an amazing Oracle AFD behaviour, which denied change on block devices respectively.

I hope you enjoyed reading this post.

Leave a reply:

Your email address will not be published.

Captcha loading...