Adicionando disco a um ASM Diskgroup

Esta sendo demonstrado neste post como adicionar um disco ao Disk Group do Oracle ASM.

Primeiramente a instancia do ASM deve ser capaz de enxergar o disco como canditado.

Formatar Unidade

Formatar os discos candidatos no SO, no caso temos dois novos discos sem nenhuma partição valida, /dev/sdo e /dev/sdp, Abaixo demonstra de maneira rapida como formatar o dsico com fdisk, porém ha um post um pouco mais detalhado a respeito em Formatando disco no Linux.

fdisk -l 
.......

Disk /dev/sdo: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdo doesn't contain a valid partition table

Disk /dev/sdp: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

......

[root@ol5-112-rac1 ~]# fdisk /dev/sdo

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel

Building a new DOS disklabel. Changes will remain in memory only,

until you decide to write them. After that, of course, the previous

content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n

Command action

   e   extended

   p   primary partition (1-4)

p

Partition number (1-4): 1

First cylinder (1-652, default 1):

Using default value 1

Last cylinder or +size or +sizeM or +sizeK (1-652, default 652):

Using default value 652

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

Syncing disks.

Criar o Label do disco Através do ASMLIB

1 Validar se o disco não possui nenhum label atrelado:

[root@ol5-112-rac2 ~]# oracleasm querydisk /dev/sdo1

Device "/dev/sdo1" is not marked as an ASM disk

2 Criar novo label para o disco

[root@ol5-112-rac2 ~]# oracleasm createdisk DISK_DATA05 /dev/sdo1

Writing disk header: done

Instantiating disk: done

3 Validar se o disco se encontra acessivel em ambos os nodes (Caso de Cluster)

[root@ol5-112-rac1 ~]#  oracleasm querydisk /dev/sdo1

Device "/dev/sdo1" is marked an ASM disk with the label "DISK_DATA05"

[root@ol5-112-rac2 ~]# oracleasm querydisk /dev/sdo1

Device "/dev/sdo1" is marked an ASM disk with the label "DISK_DATA05"

4 Identificar o label do ASMLIB em ambos os nodes com

[root@ol5-112-rac1 ~]# oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...
Instantiating disk "DISK_DATA05"
Instantiating disk "DISK_DATA06"

[root@ol5-112-rac2 ~]# oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...

Validar se os dicos aparecem como candidatos ou PROVISIONED em ambos os nodes do RAC

SQL> column path format a20
set lines 132
set pages 50

select path, group_number group_#, disk_number disk_#, mount_status,
       header_status, state, total_mb, free_mb
from v$asm_disk
order by group_number;SQL> SQL> SQL> SQL>   2    3    4

PATH                    GROUP_#     DISK_# MOUNT_S HEADER_STATU STATE      TOTAL_MB    FREE_MB
-------------------- ---------- ---------- ------- ------------ -------- ---------- ----------
ORCL:DISK_DATA05              0          0 CLOSED  PROVISIONED  NORMAL            0          0
ORCL:DISK_DATA06              0          1 CLOSED  PROVISIONED  NORMAL            0          0
ORCL:DISK_CRS_01              1          0 CACHED  MEMBER       NORMAL         1019        709
ORCL:DISK_CRS_02              1          1 CACHED  MEMBER       NORMAL         1019        711
ORCL:DISK_CRS_03              1          2 CACHED  MEMBER       NORMAL         1019        711
ORCL:DISK_DATA01              2          0 CACHED  MEMBER       NORMAL         5114       4178
ORCL:DISK_DATA02              2          1 CACHED  MEMBER       NORMAL         5114       4180
ORCL:DISK_DATA04              2          3 CACHED  MEMBER       NORMAL         5114       4170
ORCL:DISK_DATA03              2          2 CACHED  MEMBER       NORMAL         5114       4183
ORCL:DISK_FRA01               3          0 CACHED  MEMBER       NORMAL         5114       4521
ORCL:DISK_FRA03               3          2 CACHED  MEMBER       NORMAL         5114       4519
ORCL:DISK_FRA02               3          1 CACHED  MEMBER       NORMAL         5114       4521
ORCL:DISK_FRA04               3          3 CACHED  MEMBER       NORMAL         5114       4517

13 rows selected.

Portanto agora podemos adicionar os discos no DG desejado, pois esta visivel em ambos servidores.

Adicionando o disco ao ASM Group

1 Validar valor do parametro asm_power_limit

SQL> show parameter power

NAME                                 TYPE        VALUE

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

asm_power_limit                      integer     1

SQL>

2 Adicionando o disco ao DG, esta operacao pode ser feita ainda com diversos parametros, como fazer com um power limit maior que o da instancia, configurar o failgroup e o nome doo disco:

SQL> ALTER DISKGROUP DG_DATA ADD DISK

     'ORCL:DISK_DATA05',

     'ORCL:DISK_DATA06';

SQL>   2    3

Diskgroup altered.

3 Após o disco ser considerado como adicionado ao DG, o tempo de rebalance pode ser medido atraves da consulta:

SQL>  select INST_ID, OPERATION, STATE, POWER, SOFAR, EST_WORK, EST_RATE, EST_MINUTES from GV$ASM_OPERATION where GROUP_NUMBER=2;

   INST_ID OPERA STAT      POWER      SOFAR   EST_WORK   EST_RATE EST_MINUTES

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

         2 REBAL WAIT          1

         1 REBAL RUN           1       1175       1644        389           1

SQL>

4 Verificar se o disco já faz parte do Diskgroup

SQL> SQL> column path format a20
set lines 132
set pages 50
SP2-0734:
unknown command beginning "SQL> colum..." - rest of line ignored.
select path, group_number group_#, disk_number disk_#, mount_status,
       header_status, state, total_mb, free_mb
SQL> from v$asm_disk
order by group_number;SQL> SQL> SQL> SQL>   2    3    4

PATH                    GROUP_#     DISK_# MOUNT_S HEADER_STATU STATE      TOTAL_MB    FREE_MB
-------------------- ---------- ---------- ------- ------------ -------- ---------- ----------
ORCL:DISK_CRS_03              1          2 CACHED  MEMBER       NORMAL         1019        711
ORCL:DISK_CRS_02              1          1 CACHED  MEMBER       NORMAL         1019        711
ORCL:DISK_CRS_01              1          0 CACHED  MEMBER       NORMAL         1019        709
ORCL:DISK_DATA03              2          2 CACHED  MEMBER       NORMAL         5114       4481
ORCL:DISK_DATA02              2          1 CACHED  MEMBER       NORMAL         5114       4482
ORCL:DISK_DATA01              2          0 CACHED  MEMBER       NORMAL         5114       4484
ORCL:DISK_DATA04              2          3 CACHED  MEMBER       NORMAL         5114       4481
ORCL:DISK_DATA06              2          5 CACHED  MEMBER       NORMAL         5114       4505
ORCL:DISK_DATA05              2          4 CACHED  MEMBER       NORMAL         5114       4502
ORCL:DISK_FRA01               3          0 CACHED  MEMBER       NORMAL         5114       4500
ORCL:DISK_FRA03               3          2 CACHED  MEMBER       NORMAL         5114       4497
ORCL:DISK_FRA02               3          1 CACHED  MEMBER       NORMAL         5114       4500
ORCL:DISK_FRA04               3          3 CACHED  MEMBER       NORMAL         5114       4496

13 rows selected.

SQL>

Oracle Data Guard Protection Modes

Há três tipos de proteção num ambiente com dataguard, basicamente estas configurações tem como objetivo, maximo de proteção e o maximo de disponibilidade, porém são inversamente proporcionais, quanto maior o nivel de disponibilidade menor a proteção, e conforme maior o nivel de proteção menor o nivel de disponibilidade, veremos a seguir:

Protection Modes

Maximum performance (Proteção Padrão) 

Este é o nivel maximo de proteção com a menor queda de performance na produção, as transações são comitadas conforme escritas nos online redo logs, estas são transmitidas para pelo menos um banco de standby, porém de forma assincrona, portanto o banco de produção não aguarda o retorno do standby para dar uma transação por completa.

Maximum protection

Este é o maior nivel de proteção possivel, porém também com maior degradação de performance em produção. Uma transação neste ambiente só é considerada comitada ou finalizada quando pelo um redo log dos inumeros bancos de standby possivel retorne para a produção que esta transação foi escrita do lado do standby, portanto o envio ... é feito de forma sincrona, neste modo há uma maior degradação por conta do tempo de espera no commit. Neste modo para garantir o maximo de proteção , caso o banco de dados de produção não consiga encaminhar as transações e receber o sinal de volta de pelo menos um standby, o Oracle baixa o banco de produção assim garantindo o maximo de proteção.

Maximum availability 

Este é o nivel intermediario, onde o standby trabalha com o maximo de proteção sem afetar a produtividade. Se o banco de dados de produção não conseguir encaminhar ou receber a confirmação dos dados de redo para os bancos de standby ele trabalha como se utilizasse o metodo de maxima performance, garantindo portanto a disponibilidade do banco de produção.

Atributos do serviço de transporte de redo para cada metodo

O metodo de proteção de cada ambiente é feito através do serviço de transporte de redo, redo transporte service, que é configurado através do parametro LOG_ARCHIVE_DEST_n .

Maximum Availability	Maximum Performance	Maximum Protection
Sync	Async	Sync
AFFIRM ou NOAFFIRM	NOAFFIRM	AFFIRM

Oracle Data Guard Parameters

Listas dos principais parametros relacionados ao Data Guard, suas funcionalidades e onde aplica-los.

Fal_Client - Standby Side - Networking - Configurado no lado do Standby Database, é utilizado para detectar e resolver GAPs de archives. Deve se especificar um servico de rede Oracle (Net Name), do lado do standby que é  utilizado pelo primary para entrega do archive faltante. Também reqiusita o archive perdido.

Fal_Server - Standby Side - Networking - Configurado no lado do Standby Database, é utilizado para detectar e resolver GAPs de archives. Deve se especificar um servico de rede Oracle (Net Name), de onde irá prover o archive log perdido, podendo ser outro stanby database ou primary database.

Db_Unique_Name - Primary/Standby - Este parametro é utilizado para o Data Guard indentificar de forma unica todos os bancos de dados envolvidos na configuração do ambiente.

Db_Archive_Config - Primary/Standby - Define a lista completa de Bancos de Dados Unicos (DB_UNIQUE_NAME) os quais fazem parte da configuração. É também possivel configurar se a instancia em questão pode receber ou transmitir archive.

LOG_ARCHIVE_DEST_n - Pode ser um disco interno ou um servico de rede, ele é utilizado para dizer onde o banco ira escrever as copias dos archives logs.

LOG_ARCHIVE_DEST_STATE_n - Todo destino de archive tem seu parametro de estado correspondente, com ele é possivel habilitar ou desabilitar o processo de transporte dos archives.

DB_FILE_NAME_CONVERT - Utilizado para substituir uma string dentro do caminho do nome do datafile, quando é encontrada essa string é trocada por outra string previamente determinada, é util quando o ponto de montagem ou diretorios são diferentes entre as instancias.

LOG_FILE_NAME_CONVERT - Utilizado para substituir uma strings dentro do path de origem para o destingo dos online redo logs. Quando determinada string é encontrada é substituida por outra.

Standby_File_Management - Controla se o standby irá replicar os arquivos fisicos criados ou apagados na instancia de origem (primary) para o standby. É utilizado em conjunto com o db_file_name_convert e log_file_name_convert.

Role Transitions - Switchover with Broker

Role Transitions ocorre quando por falha ou necessidade as regras de banco de dados, produção e standby mudam.

Switchover é uma operação planejada, a qual não há perda de dados e todos os bancos continuam fazendo parte da mesma configuração, mesmo que haja troca de regras.

1. Pre-requisitos

1.1 Broker devidamente configurado.

É possivel validar se a configuração do broker esta correta utilizando o comando show configuration, caso a configuração não esteja valida, ou seja reportado algum erro de parametro deve ser analisado e corrigido antes de se iniciar o switchover.

DGMGRL> show configuration

Configuration - orcl_dr

  Protection Mode: MaxPerformance
  Databases:
    orcl     - Primary database
    orclstby - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

1.2 Static Service

Verificar se o parametro StaticConnectIdentifier esta devidamente configurado em ambos os bancos de dados, caso ele esteja nulo o Oracle assume o valor, _DGMGRL., o qual é registrado automaticamente no listener de cada instancia.

1.3 Parametro do Broker LOG_ARCHIVE_MAX_PROCESSES

Este parametro deve estar configurado para no minimo 4 em cada banco que fizer parte da configuração.
LOG_ARCHIVE_MAX_PROCESSES >= 4

1.4 Confirmar se o Redolog em Standby será limpo (clear).

Antes do standby database migrar para primary database seus online redologs devem ser limpos (clear), esta operação é automatizada pelo broker, porém o parametro LOGFILENAMECONVERT deve ter sido configurado previamente.

Este parametro pode ser configurado antes do switchover pelo comando edit database do broker, porém a instancia de standby precisa ser reiniciada.

Caso queria ou/e seja necessário realizar a limpeza manual, é possivel executar os seguintes passos pelo SQLPLUS do banco de standby, antes de iniciar o switchover.

SQL> SELECT DISTINCT L.GROUP# FROM V$LOG L, V$LOGFILE LF 
     WHERE L.GROUP# = LF.GROUP# AND L.STATUS 
     NOT IN ('UNUSED','CLEARING','CLEARING_CURRENT');

SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;


Estes parametros, (StaticConnectIdentifier , LOG_ARCHIVE_MAX_PROCESSES e LOGFILENAMECONVERT) podem ser revisados através do comando show database, conforme a seguir:

DGMGRL> show database verbose orcl

Database - orcl

  Role:            PRIMARY
  Intended State:  TRANSPORT-ON
  Instance(s):
    orcl

  Properties:
    DGConnectIdentifier             = 'orcl'
    ObserverConnectIdentifier       = ''
    LogXptMode                      = 'ASYNC'
    DelayMins                       = '0'
    Binding                         = 'OPTIONAL'
    MaxFailure                      = '0'
    MaxConnections                  = '1'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    LogShipping                     = 'ON'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyParallel                   = 'AUTO'
    StandbyFileManagement           = 'MANUAL'
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '4'
    LogArchiveMinSucceedDest        = '1'
    DbFileNameConvert               = 'orcl,orclstby'
    LogFileNameConvert              = 'orcl,orclstby'
    FastStartFailoverTarget         = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    SendQEntries                    = '(monitor)'
    LogXptStatus                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    SidName                         = 'orcl'
    StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=1523))(CONNECT_DATA=(SERVICE_NAME=ORCL)(INSTANCE_NAME=orcl)(SERVER=DEDICATED)))'
    StandbyArchiveLocation          = 'use_db_recovery_file_dest'
    AlternateLocation               = ''
    LogArchiveTrace                 = '0'
    LogArchiveFormat                = '%t_%s_%r.dbf'
    TopWaitEvents                   = '(monitor)'

Database Status:
SUCCESS

DGMGRL> 

1.5 Verificar se não há GAP de archive

Verificar se os archives estão sendo devidamente, pode ser validado através das consultas a seguir:

Produção:

SQL> SELECT THREAD#, SEQUENCE# FROM V$THREAD;

   THREAD#  SEQUENCE#
---------- ----------
1  270

Standby:

SQL> SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG

     WHERE APPLIED = 'YES'

     AND RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE#

     FROM V$DATABASE_INCARNATION

     WHERE STATUS = 'CURRENT')

     GROUP BY THREAD#;  2    3    4    5    6  

   THREAD# MAX(SEQUENCE#)

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

1      268

Havendo diferença de 1 a 2 archives podemos considerar que não há GAPS entre as instancias.

1.6 Verificar se o banco de standby possui todos os tempfiles de produção.

Tempfiles criados no banco de produção não são propagados nos bancos de standby, portanto é uma boa pratica verificar se todos os tempfiles estão reflitidos em ambos bancos:

SELECT TMP.NAME FILENAME, BYTES, TS.NAME TABLESPACE

     FROM V$TEMPFILE TMP, V$TABLESPACE TS WHERE TMP.TS#=TS.TS#;

1.7 Offline Datafiles

Verificar se há algum datafile offline e traze-los online:

SQL> SELECT NAME FROM V$DATAFILE WHERE STATUS='OFFLINE';

2. Switchover

Após ter certeza de que a configuração do dataguard esta correta, realizar o switchover conforme a seguir, realizar sempre o switchover através do banco primary (produção).

Realizar, pelo broker: Switchover to ;

[oracle@os-indaia-orcl-prod trace]$ dgmgrl
DGMGRL for Linux: Version 11.2.0.3.0 - Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/oracle@orcl
Connected.
DGMGRL> show configuration

Configuration - orcl_dr

  Protection Mode: MaxPerformance
  Databases:
    orcl     - Primary database
    orclstby - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL> switchover to orclstby;
Performing switchover NOW, please wait...
New primary database "orclstby" is opening...
Operation requires shutdown of instance "orcl" on database "orcl"
Shutting down instance "orcl"...
ORACLE instance shut down.
Operation requires startup of instance "orcl" on database "orcl"
Starting instance "orcl"...
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "orclstby"
DGMGRL> show configuration;

Configuration - orcl_dr

  Protection Mode: MaxPerformance
  Databases:
    orclstby - Primary database
    orcl     - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL> 

Referencias:
Metalink: 11.2 Data Guard Physical Standby Switchover Best Practices using the Broker (Doc ID 1305019.1)
Oracle Data Guard Administration

Dataguard - Parte 4 - Criando o TAF (Transparent Application Failover)

Esta é a utima parte sobre a configuração do ambiente, para este post tirei como base a nota da Oracle, How To Configure Client Failover For Dataguard Connections Using Database Services (Doc ID 1429223.1), mas é claro, alguns ajustes foram necessários.

Num ambiente replicado algumas vezes temos a necessidade de realizar a troca de papel (role) entre as base de dados (prod/stby), esta parte final visa criar um servico com que facilite o lado do cliente quando essa troca é feita, ela é realizada através de features como Oracle Restart e Dataguard Broker, onde é possivel identificar a troca de role entre as bases e iniciar servicos. A outra parte da configuração é feita através de de configuração dos arquivos de rede.

Ambiente:

Apenas para relembrar o ambiente que foi criado anteriormente, temos configurado conforme a seguir:
Dataguard - Parte 1 - Infra-estrutura

arametro	Producao	Standby
Hostname	os-indaia-orcl-prod	os-indaia-orcl-stb
ip	192.168.1.61	192.168.1.62
SO	Oracle Linux 5.7	Oracle Linux 5.7
Oracle Version	11.2.0.3	11.2.0.3
DB Name	orcl	orcl
Instance name	orcl	orclstby
db_unique_name	orcl	orclstby
service_name	orcl	orclstby
Listener Name	listener_orcl	listener_orclstby
Listener Port	1523	1523
service_name	s_orcl_prd	s_orcl_stby

Pre-requisitos

O Oracle Clusterware deve estar instalado em ambos os servidores, produção e standby.

1. Criando o Serviço base em regra (role-based service):

Como oracle, executar os comandos a seguir:

Produção:
srvctl add service -d orcl -s s_orcl_prd -l PRIMARY -q true -e select -m basic -z 10 -w 10

Standby:
srvctl add service -d orclstby -s s_orcl_prd -l PRIMARY -q true -e select -m basic -z 10 -w 10

Legenda:

-d = Database Name

-s = Service Name ( Será utilizado no tnsnames)

-l = Role of the service

-q = HA notifications

-e = Failover type

-m = Failover method

-z = Failover retries

-w = Failover delay

Para completa referencia pode ser executado : srvctl add service -help.

2. Iniciando o Servico em Produção:

Este servico deve ser iniciado somente em produção, o banco de standby este serviço não é iniciado, caso houver uma troca de role entre os DBs o Oracle Restart e Notification Service irão se encarregar de iniciar este serviço.

srvctl start service -d orcl -s s_orcl_prd

3. Criando as entradas de rede (Tnsnames.ora)

Esta entrada no tnsnames deve ser criada em ambos banco de dados:
Note que há duas entradas para direcionar para qual servidor deve ser conectar, como a conexao é baseada em servico, de acordo com a regra do serviço refem configurado o failover é a nivel de select e é feita de 1 a 10 tentativas com intervalos de 10 segundos, até estabelecer a nova conexão ou até o timeout.

orcl_prd =
  (DESCRIPTION =
     (ADDRESS_LIST =
       (FAILOVER = ON)
       (LOAD_BALANCE = OFF)
       (ADDRESS = (PROTOCOL = TCP)(HOST = os-indaia-orcl-prod)(PORT = 1523))
       (ADDRESS = (PROTOCOL = TCP)(HOST = os-indaia-orcl-stb)(PORT = 1523))
     )
     (CONNECT_DATA =
       (SERVICE_NAME = s_orcl_prd)
     )
  )

Menu Inicial: Dataguard