Pages

Friday 30 December 2011

ORACLE VAULT EXCERPTS FROM (KARAN AND VINAY)


Well i just had a strong sweet coffee and feeling good about vault already down in delhi..

Some very very important tips for Oracle Vault Security DBA's, please do read the following tips :=

1) Firstly you need to have advanced security option enabled in your oracle system.
2) When you install vault you need label security also, so label security is also needed to work with vault.
3) You will see 2 roles now DV_OWNER and DV_ACCTMGR

DV_OWNER gets roles like DV_ADMIN, DV_PATCH_ADMIN, DV_STREAMS_ADMIN, DV_SECANALYST so that he can log on to database vault administrator and modify vault configurations but the interesting fact is that he cant change user passwords and even sys and system users now cannot change passwords. Not even they can simply access objects if they are protected by realms.

DV_ACCTMGR on the other hand can only create users and modify their passwords. And 1 special thing which everybody loves is that DV_ACCTMGR cannot modify the password of DV_OWNER.

Please try to understand sys and system are no more powerful users, they cannot create users and cannot even change anybody's passwords, however they can change their own passwords, obviously. Thats why we have vault owner which is mentioned at the time vault installation, this vault manager created user will be the master here for security responsibilities.

DV_OWNER can modify vault security configurations, and can also disable security components and auditing. NOTE = SYS and SYSTEM cannot create users now after vault configurations.

There is another role which is DV_ACCTMGR for the seperation of responsibilties. Let us say that KARAN is the vault owner with DV_OWNER role and ASHISH is the the one with DV_ACCTMGR role. Now ashish can modify passwords of all users and create users but he cannot change password of DV_OWNER. Otherwise imagine if he was able to change password of KARAN then ASHISH would have added a user to the realm, do the damage and drop the user from realm, thats why KARAN is the one who is responsible for REALMS, RULE SETS , FACTORS and so on ...

Database views = DBA_DV_REALM, DBA_DV_REALM_OBJECT, DBA_DV_REALM_AUTH

DVSYS schema contains procedures to create|modify|delete a realm. Everything you do from DVA can be done using API.
Procedures are in the DVSYS.MACADM.

Have a nice day DBA's ..

                           ---------------------------

HOME

Related links:



CHECKPOINTS CONFUSIONS CLEARED FROM KARAN

Well, lot of DBA's in this world are still unaware about checkpoint facts, after having a lovely breakfast i decided to post on this....

  An RBA indicates position in the redo log. CKPT records checkpoint information to controlfile for maintaining book keeping information like checkpoint progress. Each instance checkpoint refers to some RBA (called checkpoint RBA) whose redo prior to this RBA have been written to disk. Hence recovery time is difference between checkpoint RBA and end of the redo log.

Given a checkpoint RBA, DBWR writes buffers from the head of the queue  until low RBA of the buffer at the head of the checkpoint queue is greater than the checkpoint RBA. At this point ,CKPT can record this checkpoint progress record in control file (phase 3). Phase (1) process initiating the checkpoint (checkpoitn RBA or current RBA is marked) (The RBA of the last change made to a buffer) at the time reuqest is initiated. PHASE 2 = DBWR writes all required buffers i.e all buffers that have been modified at RBAs less than or equal to the checkpoint RBA. After all required buffers have been written, in 3rd phase , CKPT process records the completion of the checkpoint in control file.

# BCQ (buffer checkpoint queue) which contains modified buffers linked in ascending oreder of their low RBAs. In response to a checkpoint request, buffers are written from the head of the checkpoint queue, i.e in ascending order of low RBA values. after the buffer is written it is unlinked from checkpoint queue.

# ACQ (active checkpoint queue) is a queue that contains active checkpoint requests. Whenever a checkpint request is made , a new active checkpoint entry describing the request is added to the ACQ. Note that multiple checkpoint requests can be there in ACq like datafiles has to checkpointed before they are backed up, alter system checkpoint, or at log switch.

# Periodically CKPT can record this low RBA to controlfile (using a very light weight controlfile update protocol). This periodically recorded lowest low RBA is current position of the incremental checkpoint for this instance.

# so incremental checkpointing greatly improves crash recovery times with negligible impact on normal activity.

# IF DBWR continiually writes from the head of the checkpoint queue, the instance checkpoint (lowest low -RBA of modified buffers) will keep on advancing.

The low and high RBAs for dirty buffers can be seen in X$BH. (There is also a recovery RBA which is used to record the progress of partial block recovery by PMON.) The incremental checkpoint RBA, the target RBA and the on-disk RBA can all be seen in X$TARGETRBA. The incremental checkpoint RBA and the on-disk RBA can also be seen in X$KCCCP. The full thread checkpoint RBA can be seen in X$KCCRT.

The checkpoint RBA is copied into the checkpoint progress record of the controlfile by the checkpoint heartbeat once every 3 seconds. Instance recovery, when needed, begins from the checkpoint RBA recorded in the controlfile. The target RBA is the point up to which DBWn should seek to advance the checkpoint RBA to satisfy instance recovery objectives.

The on-disk RBA is the point up to which LGWR has flushed the redo thread to the online log files. DBWn may not write a block for which the high RBA is beyond the on-disk RBA. Otherwise transaction recovery (rollback) would not be possible, because the redo needed to undo a change is always in the same redo record as the redo for the change itself.

The term sync RBA is sometimes used to refer to the point up to which LGWR is required to sync the thread. However, this is not a full RBA -- only a redo block number is used at this point.

-----------------------------------------------------------------------------------------------------------

Related links:

HOME


CASE STUDY ON BUFFER BUSY WAIT EVENT
CHECKPOINTS CONFUSIONS CLEARED
ORACLE CHECKPOINTS
ORACLE DATABASE BUFFER CACHE
SIMULATE BUFFER BUSY WAIT AND IDENTIFY HOT OBJECT
 CONSISTENT READS IN ORACLE PART-I



CONSISTENT READS IN ORACLE PART-II 

FLUSH BUFFER CACHE