Arquivo mensais:junho 2015

Flex ASM

Publicado em por
Responder

Um dos problemas que temos ao utilizar o ASM e que, nas versoes anteriores a versao 12c, temos que instalar a instancia ASM em cada local onde sera consumido dos diskgroups.
Temos entao o Flex ASM e para a clusterizacao temos que utilizar o Flex Clusters.
Caracteristicas:
Flex ASM nao requer Flex Cluster
Flex ASM roda como um servico para cluster padrao para atender clientes atraves do cluster.
Flex ASM pode rodar como um hub de conexao para atender aos servicos de Flex Cluster atraves de nos de HUBs de Flex Cluster.
O Flex ASM tem menor gastos de recursos ja que o mesmo nao precisa da instancia ASM
Flex ASM introduz uma nova rede para que os clientes e as instancias ASM possam se comunicar nessa rede
Como ocorre a conexao:
Cada servidor contendo o banco de dados oracle ira configurar o local_listener apontando para o listener existente no servidor que roda a instancia ASM com seu devido Listener, sendo que o parametro local_listener do banco pode ser configurado para ate 3 listener.

As instancias ASM sao desenvolvidas para que tenhamos o minimo de monitoramento o possivel. Portanto sempre que possivel a recomentacao e utilizar o parametro memory_target. O calculo e feito na hora da criacao da instancia ASM baseando-se no numero de cores dos processadores e a quantidade de memoria disponivel. Atualmente o valor minimo e de 1076M para o memory_target.
Gerenciamento
$ srvctl status asm -detail

ASM is running on host03,host02,host01 ASM is enabled.
$ srvctl stop asm -node host03 -f
$ srvctl start asm -node host04 

$ srvctl status asm -detail

ASM is running on host04,host02,host01
ASM is enabled.
$ srvctl relocate asm -currentnode host04 -targetnode host03 $ srvctl status asm -detail
ASM is running on host03,host02,host01
ASM is enabled. 

$ srvctl stop asm -proxy -node host03 
$ srvctl start asm -proxy -node host04

Cardinalidade

A cardinalidade para as instancias ASM, informa qual e a quantidade de instancias ASM servindo o cluster ASM.

$ srvctl config asm
ASM home: /u01/app/12.1.0/grid
Password file: +DATA/orapwASM
ASM listener: LISTENER
ASM instance count: 3
Cluster ASM listener: ASMNET1LSNR_ASM

Para consultar quais sao os clientes que estao consumindo as instancias, utilizamos a gv$asm_client.

Para visualizar quais instancias estao fazendo o atendimento, faca a consulta abaixo:

 

Os clientes podem ser realocados, isso ja ocorre automaticamente caso a instancia ASM falhe. Mas atraves do novo comando abaixo, podemos realocar o cliente. Geralmente voce executa este comando para tentar realocar os clientes para outra instancia ASM.

SQL> ALTER SYSTEM RELOCATE CLIENT ‘<instance_name>:<db_name>‘;
O cliente sera desconectado e provavelmente ao se conectar novamente, ira se conectar na instancia ASM que ja estava conectado. Para evitar que isso ocorra, derrube a instancia ASM logo apos realocar todos clientes.

Quando os discos estao entregues para serem consumidos pelos diskgroups temos os seguintes status:
CANDIDATE – Disco recentemente criado, este disco nunca foi usado ainda.
FORMER – Disco que ja foi usado e removido do diskgroup, esta disponivel novamente para uso.
PROVISIONED – E similar ao candidate exceto porque o provisionado ainda necessita alguma acao por parte do administrador para disponibilizar este disco.
Para criar um diskgroup siga o exemplo:
 

CREATE DISKGROUP FRA NORMAL REDUNDANCY
DISK ‘ORCL:SDD11’ NAME ‘FRA_DISK1’ SIZE 977 M, ‘ORCL:SDD12’ NAME ‘FRA_DISK2’ SIZE 977 M;

Cada diskgroup criado, mesmo que nao contenha a clausula failure group, cada disco pertencendo a um diskgroup com redundancia normal ou redundancia high,  cada disco contem uma redundancia, ou seja se eu tiver 10 discos em um diskgroup vamos ter automaticamente 10 failgroups.
Redundancia
NORMAL – requer no minimo dois failure groups. No exemplo de criacao acima sao dois failure groups criados. Permite a falha de um failure group. Controlfiles armazenados neste tipo de diskgroup espelhado 3 vezes.
HIGH REDUNDANCY – requer a existencia de tres grupos de falha. Tolerante a perda de dois grupos de falhas.
EXTERNAL REDUNDANCY – nao tolera falhas, necessita redundancia externa.

Questao da prova 1Z0-058

Publicado em por
Responder

Assuntos das questoes 1Z0-058 sobre as informacoes abaixo:

  1. Sobre os processos do ACFS

  3. 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

  1. 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.
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