ROLES ======= A role is a named collection of system privileges, object privileges, Resource Manager Consumer groups and other

roles. Roles are owned by database and they are not part of any schema. Roles can require a password to be enabled. Roles can be enabled or disabled on a user-by-user basis. Pre-defines roles: EXP_FULL_DATABASE SELECT ANY TABLE, BACKUP ANY TABLE IMP_FULL_DATABASE Become any user CONNECT RESOURCE DBA EXP_FULL_DATABASE, IMP_FULL_DATABASE, all system privileges with ADMIN option Who may grant roles? A user must meet the following: i) Have GRANT ANY ROLE system privilege ii) Have been granted the role with WITH ADMIN OPTION iii) Be the person who created the role WITH ADMIN OPTION and system privileges: A user granted with system privilege along with the WITH ADMIN OPTION are capable of the following i) The user may grant or revoke system privileges from any user or role in the db ii) The user may grant system privileges to other users or roles along with the WITH ADMIN OPTION iii) The user may alter or drop any role that they grant to others WITH GRANT OPTION and object privileges: i) The user may grant or revoke that object privilege from/to any user or role in the db ii) The user may grant object privileges to other users or roles along with the WITH GRANT OPTION but granting a role with the WITH GRANT OPTION is not possible

By default the owner of an object has all object privileges on that object as well WITH GRANT OPTION for those privileges How are roles enabled? Manually specific roles are enabled by means of SET ROLE command ALTER USER command is used to enable default roles to a user By providing role password when required SELECT role, owner, table_name, privilege from role_tab_privs WHERE role IN (HR_APP, FINANCIAL_APP); The above SQL statement gives a series of object privilege grants given on tables that are given to HR_APP and FINANCIAL_APP roles. PROFILES ========= What are Profiles? Profiles are DB objects which serves two purposes i) Resource limit: by defining a set of resource limits and associating these limits with given users ii) Security policy: password management A created profile is associated with users by CREATE USER or ALTER A default profile named DEFAULT always exists User with ALTER PROFILE system privilege may modify the limits for DEFAULT profile Changes to a profile will apply automatically to its users, but its effect can be seen for new sessions. If a profile to be dropped is already assigned to users, then the CASCADE option must be used, when this happen s that user will be associated with default profile. How to enable profiles? By setting the RESOURCE_LIMIT parameter to TRUE ALTER SYSTEM set RESOURCE_LIMIT =TRUE scope=BOTH; Database failures ================ Categories of failures 1. Statement failure DB operation failure 2. User process failure session failure 3. Network failure DB connectivity lost

iii)

4. User error failure 5. Instance failure 6. Media failure

dropping DB object unexpected DB instance shutdown one or more DB files are lost

Remedies: 1. Statement failure: When single DB operation fails, a DBA involvement may be needed to correct errors, user privileges or db space allocation 2. User process failure: DBA action is not needed to resolve user process failures. Background process (PMON) will rollback uncommitted data and releases locks 3. Network failure: Typical problems are i) Listener fails restart listener ii) Network Interface Card NIC fails backup backup NIC iii) Network connection fails backup network connection 4. User errors Causes solution User deletes or modifies data rollback or use flashback query to recover User drops a table recover table from recycle bin Refer to hand drawn diagram for user errors 5. Instance failure: It occurs when instance is shutdown before synchronizing all the database files. As a DBA, our job is in recovering from instance failure is usually limited to restarting the instance and prevent future occurrence. Typical causes: i) Power outage ii) Hardware failure iii) Failure of one of the background processes iv) Emergency shutdown procedures INSTANCE RECOVERY: i) Is caused by attempts to open a database whose files are not synchronized ii) Is automatic iii) Uses info stored in redolog groups to synchronize files iv) Rollforward and roll backward operation occurs Phases of instance recovery i) Datafiles are out of sync ii) Roll forward (REDO)

iii) Now, datafiles contain committed and uncommitted data iv) Rollback v) Committed data in files Tuning instance recovery i) Time required for instance recovery is the time required to bring datafiles from their last check point to the latest SCN recorded in control file ii) DBA can adjust the time taken for instance recovery by setting MTTR target and size of redo group iii) The distance between check point and end of redo log should not exceed 90% of smallest redo log group. 6. Media Failure: Any failure that results in loss of one or more than one DB files is known as media failure. It needs restoring and recovering of missing files. Causes: i) Failure of disk drive ii) Failure of disk controller iii) Deletion or corruption of DB files Possible solutions i) Restoring affected files from backup ii) If necessary, recovering the file by applying redo info. iii) If necessary, inform database about new file location Control File (CF) architecture =========================== CF is small binary file and contains info about DB. CF is created when DB is created and it is updated with the physical changes. Only oracle processes should update CF, we should not edit it. Log writer process, CKPT, ARCn updates CF with log sequence#, CKPT info, archived log filename and log sequence# respectively. CF can continue to grow due to RMAN backup info recorded in the CF until it reaches CONTROL_FILE_RECORD_KEEP_TIME. Maintaining a copy of the same control file on different disk drives is known as MULTIPLEXING control files. Max of 8 is possible. Multiplexing CFs will increase the time taken to update all the control file when changes occur. Initialization parameter: CONTROL_FILES

Though all the CFs are updated at the same time, Oracle uses only first CF listed in the CONTROL_FILES parameter. FLASH RECOVERY AREA (FRA): The rapid access feature of disks is the reason that any DB recovery operation takes only minutes instead of hours. FRA is a single, unified storage area for all recovery file and activities in an oracle DB. FRA can be a single directory, an entire file system or ASM disk group. FRA can be shared by more than one database. A copy of control file can be used as one of the mirrored copies of the control file to ensure that at least one copy of the control file is available after a media failure. Initialization parameter LOG_ARCHIVE_DEST_10 is automatically set to the FRA location. If flashback database is enabled, its flashback logs are stored in FRA. When RMAN backsup datafile #1, the CF is automatically included in the RMAN backup. RMAN backup AS COPY for image files, the default destination for the data file copies is FRA. By default, RMAN uses FRA for both backup sets and image copies. To setup FRA we must initialize DB_RECOVERY_FILE_DEST_SIZE, DB_RECOVERY_FILE_DEST. DB_RECOVERY_FILE_DEST_SIZE must be defined before DB_RECOVERY_FILE_DEST parameter. All instances in RAC DB must have the same value for DB_RECOVERY_FILE_DEST_SIZE, DB_RECOVERY_FILE_DEST. Clearing the value for DB_RECOVERY_FILE_DEST disables FRA. The parameter DB_RECOVERY_FILE_DEST_SIZE cannot be cleared until DB_RECOVERY_FILE_DEST parameter has been cleared. Each time a file is deleted from the FRA, a message is written to the alert log.