Which three statements are true about Global Resource M…

Which three statements are true about Global Resource Management in an Oracle 12c RAC database?

Which three statements are true about Global Resource Management in an Oracle 12c RAC database?

A.
Lazy remastering occurs when an instance shuts with SHUTDOWN IMMEDIATE.

B.
Object remastering causes all blocks in any instances’ buffer cache from the same object to be mastered in the Global Resource Directory (GRD).

C.
When a database instance fails, then some global resource masters lost from the failing instance are remastered among the surviving instances.

D.
Lazy remastering instances occurs when an instance shuts with SHUTDOWN TRANSACTIONAL.

E.
Global Enqueue resources are recovered after Global Cache Resources after an instance failure.

Explanation:



Leave a Reply 10

Your email address will not be published. Required fields are marked *


godo77

godo77

A, C and D are correct

WGCM

WGCM

“A”, “B” and “C”

I think that “A” is correct!

“When an instance shuts down gracefully—meaning normal, immediate, or transactional, then resources mastered by the terminating instance are handed off to the surviving instances by using an optimized internal algorithm designed to minimize the remastering and subsequent concurrency control overheads.”

I think that “B” is right!

“Global Resource Directory (GRD)
• An object under global concurrency control is called a resource.
• Resource metadata is held in the Global Resource Directory (GRD).
— Global enqueue resources are used for enqueues and locks.
— Global cache resources are used for buffer cache control.
• The GRID is distributed among all active instances of each database or ASM environment.
• Each currently managed GRID resource has:
— A master metadata structure
— One or more shadow metadata structures

A master metadata structure contains information about the state of the related resource for each instance in which that resource resides. A shadow metadata structure only contains information about the state of the related resource in the instance containing the shadow metadata.”

I thing that “C” is right:

“Global Resource Recovery
• When one or more but not all instances fail:
— The failing instance(s) resource masters are lost
— Any resource master that had a shadow in a surviving instance must be recovered
• The surviving instances can rebuild resource master metadata for a specific resource, by aggregating details from surviving shadow metadata for the same resource.
. Global locks and enqueue metadata are done first, followed by global cache metadata.
. The rebuilding results in each surviving instance mastering some of the recovered resource master metadata.”

I think that “D” is wrong… “Lazy remastering INSTANCES…”

I think that “E” is wrong!

“Global locks and enqueue metadata are done first, followed by global cache metadata.”

Someone more can help?!

Tri Ho Quoc

Tri Ho Quoc

Hi WGCM,

I think C is wrong.

C: When a database instance fails, then some global resource masters lost from the failing instance are remastered among the surviving instances.

The C will be right if the statement is:
When a database instance fails, then all global resource masters lost from the failing instance are remastered among the surviving instances.

All master resources are remaster not some.

Tri Ho Quoc

Tri Ho Quoc

Hi WGCM,

B is also wrong

Object remastering causes all blocks in any instances’ buffer cache from the same object to be mastered in the Global Resource Directory (GRD).
Not in any instances’ buffer cache. Only the master object on failed instance is remastered. The master object on another instances won’t change.

godo77

godo77

Hi,

I mean A and D because Lazy remastering occurs when oracle shutdown gracefully, that is shut immediate or shut transactional.

godo77

godo77

ahhh sorry, its true “D” is wrong

WGCM

WGCM

In the Exam, the word “instance” does not appear! In this case, the answers “A” and “D” is correct!

WGCM

WGCM

So, i think that the best choice is “A”, “C” and “D”…

When an instance fails and the failure is detected by another instance, the second instance
performs the following recovery steps:
1. During the first phase of recovery, Global Enqueue Services remasters the enqueues.
2. The Global Cache Services (GCS) remasters its resources. ***The GCS processes
remaster only those resources that lose their masters***. During this time, all GCS
resource requests and write requests are temporarily suspended. However, transactions
can continue to modify data blocks as long as these transactions have already acquired
the necessary resources.
3. After enqueues are reconfigured, one of the surviving instances can grab the Instance
Recovery enqueue. Therefore, at the same time as GCS resources are remastered,
SMON determines the set of blocks that need recovery. This set is called the recovery
set. Because, with Cache Fusion, an instance ships the contents of its blocks to the
requesting instance without writing the blocks to the disk, the on-disk version of the
blocks may not contain the changes that are made by either instance. This implies that
SMON needs to merge the content of all the online redo logs of each failed instance to
determine the recovery set. This is because one failed thread might contain a hole in the
redo that needs to be applied to a particular block. So, redo threads of failed instances
cannot be applied serially. Also, redo threads of surviving instances are not needed for
recovery because SMON could use past or current images of their corresponding buffer
caches.
4. Buffer space for recovery is allocated and the resources that were identified in the
previous reading of the redo logs are claimed as recovery resources. This is done to
avoid other instances to access those resources.
5. All resources required for subsequent processing have been acquired and the Global
Resource Directory (GRD) is now unfrozen. Any data blocks that are not in recovery can
now be accessed. Note that the system is already partially available.
Then, assuming that there are past images or current images of blocks to be recovered
in other caches in the cluster database, the most recent image is the starting point of
recovery for these particular blocks. If neither the past image buffers nor the current
bufferfora data block is in any of the surviving instances’ caches, then SMON performs
a log merge of the failed instances. SMON recovers and writes each block identified in
step 3, releasing the recovery resources immediately after block recovery so that more
blocks become available as recovery proceeds.
After all the blocks have been recovered and the recovery resources have been released, the
system is again fully available.
In summary, the recovered database or the recovered portions of the database become
available earlier, and before the completion of the entire recovery sequence. This makes the
system available sooner and it makes recovery more scalable.
Note: The performance overhead of a log merge is proportional to the number of failed
instances and to the size of the amount of redo written in the redo logs for each instance.

JipeenLee

JipeenLee

Agree with A and D,
not sure about the others…