Assuntos das questoes 1Z0-058 sobre as informacoes abaixo:
- Sobre os processos do ACFS
- Additional processes are started when ADVM volumes are configured.
- VDBG: The Volume Driver Background process forwards ASM requests to lock or unlock an extent for volume operations to the Dynamic Volume Manager driver. The VDBG is a fatal background process, the termination of this process brings down the ASM instance.
- VBGn: Volume Background processes wait for requests from the Dynamic Volume Manager driver, which need to be coordinated with the ASM instance. An example of such a request would be opening or closing an ASM volume file when the Dynamic Volume Manager driver receives an open for a volume (possibly due to a file system mount request) or close for an open volume (possibly due to a file system unmount request). The unplanned death of any of these processes does not have an effect on the ASM instance.
- VMB: Volume Membership Background coordinates cluster membership with the ASM instance.
Sobre redundancia do diskgroup
- There are always failure groups even if they are not explicitly created. If you do not specify a failure group for a disk, that disk is placed in its own failure group with the failure group name the same as the disk name Therefore, if 20 disks were in a single disk group, there could be 20 failure groups as well. Failure groups have meaning only when used with normal and high redundancy disk groups. All failure groups within the same disk group should be created with the same capacity to avoid space allocation problems.
Sobre Quiescing no RAC
Quiescing a database
For maintenance purposes you may require a database to be quiesed, so that the only connections allowed are as sys or system. Even users with the DBA role will be excluded.
This mode is useful for:
Transactions that would otherwise fail if user transactions access the same object or set of objects. Things like changing the schema of a database table, or adding a column to an existing table where a no-wait lock is required.
Multistep procedures, that could confuse application users, if they were still logged on. For example exporting dropping an re-creating a table.
Quiescing the database will have a similar effect to shutting the database down, and restarting it in restricted mode. However on a high availability system, you may not be able to shut the database down. Quiescing would have a smaller impact then the shutdown and restart.
To place a database into quiesced mode:
SQL> alter system quiesce restricted;
Non-DBA active session will continue until they become inactive. An active session is a session that is inside a transaction or a session that is currently holding shared resources. No inactive sessions are allowed to become active. When a connected user issues a query, the query will seem to hang until the databas
e is taken out of quiesced state, and the query will then continue.
e is taken out of quiesced state, and the query will then continue.
Once all of the Non-DBA active sessions have become inactive, then the “SQL> alster system quiesce restricted;” completes, and the database is then in a quiesced state. In a RAC environment, this statement will affect all the instances, and not just the instance where the statement was issued from.
While waiting for this statement to process you can query from another session SID(session ID) from v$blocking_quiesce view. You can join this view with v$session to get more information about the session.
SQL> select bq.sid, ses.user, ses.osuser, ses.type, ses.program
From v$blocking_quiesce bq,
V$session ses
Where bq.sid = ses.sid;
If your session terminates, or you cancel the request to quiesce the database, then the Oracle Database automatically reverses any partial effects of the statement.
For queries that are carried out by successive OCI(Oracle Call Interface) fetches, the Oracle database only waits for the first fetch to complete.
The mechanism works the same for dedicated and shared server connections. The user trying to login after the quiesce statement has been issued, will experience it as though the login as hung. The login will continue again when the database is unquiesced.
The database will remain in this state, regardless of whether the session that issued the statement is still active or not. In order to take the database out of this mode a DBA(sys,system) will need to log in and unquiesce the database. In a RAC environment, the unquiesce statement can even be issued from a different instance.
SQL> alter system unquiesce;
A quiesced database is not in the correct state for a cold backup, because the file headers are still being updated. However an online backup in this state is possible.
To view the QUIESCE state of an instance, you can:
SQL> select active_state from v$instance;
The possible values returned are:
· NORMAL – Normal unquiesced state
· QUIESCING – Being quieced, but some non-DBA sessions are still active
· QUESCED – Quiesced, non non-DBA sessions are active or allowed
