Menu de navegação

[mpunganParticipante]

Pessoal segue abaixo o erro que esta dando no ambiente de desenvolvimento. Se alguém puder dar uma força. Esta ambiente esta numa máquina virtual em uma máquina manfraime. Esta usando o SO IBM: Linux on System z, utilizando o linux Suse-10.

SQL> ALTER DISKGROUP ALL MOUNT
Wed Sep 8 10:38:05 2010
NOTE: cache registered group DGORADB number=1 incarn=0xc9119c12
Wed Sep 8 10:38:05 2010
Loaded ASM Library – Generic Linux, version 2.0.4 (KABI_V2) library for asmlib interface
Wed Sep 8 10:38:05 2010
ERROR: no PST quorum in group 1: required 1, found 0
Wed Sep 8 10:38:05 2010
NOTE: cache dismounting group 1/0xC9119C12 (DGORADB)
NOTE: dbwr not being msg’d to dismount
ERROR: diskgroup DGORADB was not mounted
Wed Sep 8 10:44:26 2010
SQL> alter diskgroup DGORADB mount

Wed Sep 8 10:44:26 2010
NOTE: cache registered group DGORADB number=1 incarn=0x14a19c18
Wed Sep 8 10:44:26 2010
ERROR: no PST quorum in group 1: required 1, found 0
Wed Sep 8 10:44:26 2010
NOTE: cache dismounting group 1/0x14A19C18 (DGORADB)
NOTE: dbwr not being msg’d to dismount
ERROR: diskgroup DGORADB was not mounted

[CleitonHanzenParticipante]

Olá…

Este ambiente é Single-Instance ou é RAC? Se for RAC, este problema se apresenta em todos os nós?
Na instance ASM você consegue ver todos os discos na view v$asm_disks? Qual o valor do parâmetro asm_diskstring na instance ASM?

Foi mexida alguma coisa na infra-estrutura (storage, switch san, lun’s, etc..etc..)?

[jspaulonciParticipante]

Oi mpungan, qual é o SO ? se for Linux verifique se teve alguma atualização de kernel ?

[mpunganParticipante]

Cleiton, essa instance é um RAC, este problema se apresenta em todos os nós, pois não conseguimos subir a instance. O valor do parâmetros asm_diskstring esta com valor 0. Não consigo pesquisar essa view porque o banco não esta aberto.

O que aconteceu foi o seguinte:

Após a migração do switch SAN, ficamos com uma pendencia, o RACDES. Na troca do switch quando fomos subir as LRAC dava uma mensagem de erro de acesso a disco como se disco estivesse corrompido (DASD FF07 error reading volid), tentamos corrigir colocando um volid, sem sucesso. Após várias tentativas verificamos que havia um problema de contato na fibra entre o mainframe e switch que gerava o erro no acesso.

[CleitonHanzenParticipante]

Opá…

Pelo jeito você está usando ASM Lib aí, certo? se executar o script /etc/init.d/oracleasm scandisk e listdisk aparece alguma coisa?

Essas migrações de storage/switch san sempre são enroladas, já vi um monte de M… acontecer somente pela mudança no “zoning” (sei lá se é assim q se escreve)….

Bom, eu iria para checagem se todas as LUN’s estão corretamente apresentadas nos servidores, já que este problema não é nada relacionado ao Oracle em si e sim com LUN’s que não estão sendo “localizadas” pelo ASM.

[]s

[mpunganParticipante]

Cleiton eu consigo enchergar a v$asm_disk, fiz o select abaixo e retornou o seguinte:

SQL> select group_number, disk_number, incarnation, mount_status
2 from v$asm_disk;

GROUP_NUMBER DISK_NUMBER INCARNATION MOUNT_S

---

       0           0           0 CLOSED
       0           1           0 CLOSED
       0           5           0 CLOSED
       0           3           0 CLOSED
       0           4           0 CLOSED
       0           2           0 CLOSED

[PetersonParticipante]

Pelo software da storage, você consegue ver se todas as LUNS estão OK e se estão corretamente atribuídas aos devidos hosts?

[mpunganParticipante]

SQL> select * from v$asm_diskgroup;

GROUP_NUMBER NAME SECTOR_SIZE BLOCK_SIZE

---

ALLOCATION_UNIT_SIZE STATE TYPE TOTAL_MB FREE_MB

---

REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB OFFLINE_DISKS U

---

COMPATIBILITY

DATABASE_COMPATIBILITY

       0 DGORADB                                512       4096
         1048576 DISMOUNTED                  0          0
                  0              0             0 N

GROUP_NUMBER NAME SECTOR_SIZE BLOCK_SIZE

---

ALLOCATION_UNIT_SIZE STATE TYPE TOTAL_MB FREE_MB

---

REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB OFFLINE_DISKS U

---

COMPATIBILITY

DATABASE_COMPATIBILITY

0.0.0.0.0
0.0.0.0.0

SQL> SELECT name, header_status, path FROM V$ASM_DISK;

NAME HEADER_STATU PATH

---

                           MEMBER       /dev/raw/raw4
                           MEMBER       /dev/raw/raw5
                           FOREIGN      /dev/raw/raw1
                           CANDIDATE    /dev/raw/raw3
                           FOREIGN      /dev/raw/raw2
                           MEMBER       /dev/raw/raw6

[CleitonHanzenParticipante]

Opá…

Estes RAW Devices existem nos servidores?

[jspaulonciParticipante]

Qual é o SO ? Você está usando RAW DEVICE ? O Linux a partir da 5.0 não dá suporte a RAW.

Tente alterar o seu asm_diskstring para /dev/oracleasm/disks/*

Tente subir a asm

[CleitonHanzenParticipante]

Opá….

Pelo post é Suse Linux 10 em IBM System Z.

Só fique atento à questão de Raw Devices no RHEL 5, desde a versão 5.4 foi “retornado” o suporte a raw devices, conforme pode ser lido no release notes:

“Previously, support for raw devices in the upstream kernel was deprecated. However, this support has been returned to the kernel. Consequently, in Red Hat Enterprise Linux 5.4, support for raw devices has also been returned. Additionally, the initscripts packages have been updated, adding the previously dropped functionality of raw devices”

Fonte: http://www.redhat.com/docs/en-US/Red_Ha … ase_Notes/

E mesmo assim sem “suporte”, dava pra fazer via udev ou até mesmo no inittab via comando “raw”.

[]s

[mpunganParticipante]

Cleiton, esses row devices existem no servidor, estão lá.

[CleitonHanzenParticipante]

Opá…

Só em nível de testes faça o seguinte:

• Apresente uma LUN nova para este grupo de servidores
• Crie um Raw Device novo em cada um dos servidores (associe um nome que ainda não está em uso)
• Crie um novo Diskgroup no ASM utilizando este novo raw device e veja se é possível montá-lo em todos os servidores

Caso este procedimento seja bem sucedido, muito provávelmente ocorreu das antigas LUN’s ficarem “corrompidas” (algo como se o storage/servidores não “enxergassem” os dados contidos nela), neste caso só quem gerencia a storage/switch san pode averiguar se não há nenhum erro de configuração.

Como te informei anteriormente, este tipo de problema NÃO aparenta ser NADA com o software Oracle em si, e sim alguma problema (erro de config. ) da infra.

O que você pode checar também, é o Major/Minor destes raw devices e ver se estão apontando para os discos corretos, como vocês sofreram com mudanças de switch san isso pode ter bagunçado a forma como os servidores estão identificando os discos.

Enfim, não vejo muito mais que possamos ajudar enquanto DBA’s, pede ajuda dos xirus da infra aí e reze pra que eles consigam encontrar o problema. Caso contrário, só refazendo o ambiente e voltando backup….. 😛

[jspaulonciParticipante]

mpungan esse ambiente é produção ?

Qual o tamanho dos diskgroups ?

Tudo o que o Cleiton está dizendo faz sentido.

[Autor]

Posts