Um dos pontos que sempre perguntam sobre o Exadata é sobre a sua atualização, como ela é ou pode ser atualizado? Como o seu storage é atualizado? Realmente, e sendo franco, a sua atualização não é uma das mais simples no universo Oracle.

Simplificando, a sua atualização pode ser dividida em duas partes, a primeira é a atualização do software Exadata que roda nos storage nodes. A segunda parte é a atualização dos dbnodes, e esta última pode levar a mais algumas.

Desta forma, dividirei este post em dois. Primeiro falando da atualização dos storage nodes. E um segundo post falando da atualização dos dbnodes.

Antes de começar a falar sobre a atualização em si é importante saber onde você está indo. Traçar um mapa do que deve ser feito, dos passos importantes que serão tomados, das notas do Metalink com as informações importantes e dos contatos necessários.

Se eu não me engano, atualmente no contrato de aquisição já estão embutidas horas de atualização do Exadata pela equipe Oracle Advanced Customer Support (ACS), sendo horas para atualização a cada três ou quatro meses. De qualquer forma nada impede que a atualização do Exadata seja feita sem acompanhamento da equipe ACS, ou mesmo que eles estejam presentes que a atualização não seja feita por eles.

O profissional da ACS que estiver acompanhando a atualização servirá de ponte entre você, a atualização e a equipe de desenvolvimento do Exadata Oracle. Caso ocorra um erro durante a atualização, ao você abrir a SR, o ACS presente poderá intervir e priorizar o atendimento. A equipe de suporte da Oracle que está atendendo a SR saberá que se o ACS presente não conseguiu resolver o problema, ele é grande. Como pode ser notado, o fluxo é o mesmo, a presença do ACS não desobriga abertura de um SR. Em caso de erro na atualização o único caminho é esse, abertura de SR e espera por reposta (mesmo com um ACS sentado ao seu lado).

Assim, você pode solicitar ao ACS presente que a atualização seja feita por você e não por ele, que ele acompanhe a sua atualização. Nos Estados Unidos é comum este método. Acredito que este tipo de trabalho seja interessante, pois existe a possibilidade de aprender diversas etapas que não são comuns na administração do Exadata. No TJ o caso é mais peculiar, por sermos o segundo Exadata no Brasil (primeiro OLTP e ainda um V2) comprado nos idos de 2010 não temos horas ACS disponíveis (isso não existia no contrato naquela época). Assim temos que fazer por nós mesmo ou adquirir horas de suporte.

A atualização do Exadata é liberada a cada quatro meses, assim temos três versões principais por ano. Estes patchs são chamados de Quarterly Database Patch for Exadata (QDPE) e incluem Critical Patch Update (CPU) e Patch Set Update (PSU) que foram homologados nos laboratórios da Oracle. Em alguns casos especiais versões são lançadas em um tempo mais curto, tornando obsoleta a anterior. Isso ocorreu com a 11.2.3.1.1 que substitui a 11.2.3.1.0 em um período de menos de um mês, ou até mesmo da 11.2.2.3.1 que foi marcada como withdrawn (tinha um bug no firmware da controladora que causava a perda dos discos).

A atualização do Exadata, do software presente no storage nodes e dos dbnodes, está contida em um único arquivo. Assim, a atualização contêm as novas versões do software do Exadata, do kernel do Linux (e seus pacotes), patchs ou novas versões de firmwares de discos e suas controladoras e ILOM. O patch do Exadata não atualiza o switch Infiniband, este é atualizado através de um pacote separado.

O ponto inicial para iniciar um projeto de atualização do Exadata é começar pela nota 888828.1 do Metalink. Nesta nota existem informações sobre as versões disponíveis, qual a última lançada, e a compatibilidade entre elas. Uma informação importante contida lá é sobre a versão do kernel do Linux presente nas versões do Exadata.

A versão do kernel é importante, pois é necessário manter as versões do dbnode e storage node compatíveis no mesmo kernel.  Versão diferentes não são comuns, mas no caso de um rollback forçado de versão podemos ter incompatibilidade com o OFED. Resumindo, o OFED é o driver/software de acesso a Infiniband provido pela Oracle e ele está intimamente ao kernel e ao software do Exadata.

Através desta nota podemos traçar o projeto da atualização, identificar as notas específicas da versão desejadas e as critical issues que podem ocorrer. Neste caso, estamos atualizando para a versão 11.2.3.1.1 (que é última até a data atual) e a nota sobre esta versão é a 1466459.1.  No meu caso, estou saindo da 11.2.2.3.5 para a última.

Com base no histórico de atualizações já aplicadas aqui e com base nas notas alguns pontos devem ser verificados antes de começar o patch em si:

• Verificar ILOM: Já peguei alguns casos em que a ILOM estava travada, neste caso deve-se verificar se o acesso a ela está ok, caso contrário deve ser reiniciada (um processo bem simples que não reinicia o nó, somente a ILOM).
• Desligar o GRID: Caso você tenha (deveria caso não o tenha) o seu Exadata sendo monitorado pelo Grid Control (11 ou 12) seria importante desligar o monitoramento ou até mesmo o GRID. Assim qualquer restart chamado pelo GRID por erro no acesso a célula pode ser evitado.
• Desligar ASR: O ASR serve para o monitoramento do hardware do Exadata, como o patch atualiza os firmwares de disco e controladoras, não quero nenhuma SR sendo aberta por erro de acesso durante a atualizaçã
• Desligar backups: Não quero backups (ou e-mails de erro) ocorrendo no meio do meu patch.
• Verificar a nota 1270094.1: Esta nota contêm os critical issues gerais do Exadata e alguma incompatibilidade pode estar listada lá.

Estas são as linhas gerais que podem ser observadas e influenciar o patch. Pode ser que não seja possível parar o backup em um final de semana específico por exemplo, ou o GRID necessite ficar online, ou até mesmo uma issue não resolvida entre o banco e o software do Exadata que seja imprescindível no seu ambiente.

Avançando um pouco mais, temos a atualização dos storage nodes. Como citei, estamos indo para a última versão, presente no patch 13998727 e descrito na nota 1466459.1. Apesar da existência desta nota, o manual a ser seguido é o readme que acompanha o patch. As informações contidas ali são muito mais detalhadas que qualquer nota do Metalink.

Novamente é importante traçar um passo a passo do que será feito, identificando qualquer problema que possa surgir. Com base em experiências anteriores, nas notas e no readme associado acho importante:

• Versão do banco deve ser BP12: Os binários do Oracle do dbnode devem estar com o BP12 no mínimo, se não estiver devem ser atualizados.
• Versões a que se aplica: Todo o patch de storage tem uma lista de versões que podem ser atualizadas, no meu caso a versão 11.2.2.3.5 pode ser atualizada diretamente para a última. Em alguns casos pode ser necessário atualizar para uma intermediária.
• Modo do patch: Da mesma forma que um patch de RAC ele pode ser rolling ou no-rolling. Neste caso depende do seu ambiente, no meu o patch foi no modo no-rolling. A negociação para conseguir tal janela foi imensa.
• Versão do Infiniband Swicth: Neste caso o requisito era a versão 1.3.3-2, para identificar isso, basta um simples login no switch (via ssh) e digitar nm2version.
• Verificar o sistema de arquivos: Importante verificar se não existe nada montado como somente leitura nos seus storage nodes (em todos). Se estiver, corrija.
• Verificar os IP’s: verifique se os IP’s definidos nos arquivos cell.conf e cellip batem com a topologia atual.
• Verifique o VNC: Um método importante, passado pelo ACS, é rodar o patch via VNC a partir de um dbnode. Não se recomenda o uso via ILOM pois esse pode travar ou ser atualizado pelo processo.
• Verificar os issues listados no readme: Saber o que já deu errado em outras atualizações ajuda caso o mesmo ocorra na sua. Essas informações foram coletadas pela Oracle e estão presentes no readme do patch.

Algo que notei durante o patch foi com a ILOM, já tive casos em que um simples reboot demorou mais do que 10 minutos para ser realizado. Esses 10 minutos ocorreram entre o fim do reboot do Linux e o boot da bios. Isso é um bug (corrigido na última versão) presente na ILOM. O detalhe aqui é que o patch disparado tem um timeout para considerar se não houve erro, esse timeout é curto e o patch entende que a demora foi causada por um erro na sua aplicação e cancela tudo, fazendo rollback de tudo em todos os nós. Como isso não é legal recomendo reiniciar todas as ILOM’s (de todos os nós e dbnodes), bem como um reboot geral do seu Exadata antes de iniciar tudo, parece estranho (e é) mas pode evitar problemas. Isso está listado nas entrelinhas do issue 6 do readme do patch.

Antes de aplicar o patch acho importante definir os passos que serão realizados, a nota do patch e seu readme são extensos e criar um passo a passo julgo ser fundamental. Na aplicação deste patch os passos que mapeados foram:

• Download e unzip do patch.
• Download de qualquer fix presente na nota do patch.
• Verificar o arquivo cell_group, se todos os storage nodes estão ali listadas.
• Realizar o patch­_check_prereq.
• Aplicar o patch via patchmgr.
• Acompanhar os logs e ILOM durante a aplicação.
• Após patch verificar o imagehistory e imageinfo.
• Localizar por falhas nos arquivos de log.
• Se sucesso realizar o cleanup.
• Checar o IBS por erros em portas.

Com os passos mapeados podemos prosseguir com a aplicação do patch. Partindo de um download do patch diretamente do Metalink temos que copiá-lo para um dbnode. A aplicação do patch não é chamada diretamente no storage node, o patch reside no dbnode e é aplicado nos storages. Por isso, é necessário que exista a equivalência de ssh para root entre todos os servidores do Exadata. Além disso, deve-se iniciar uma seção VNC com o dbnode e realizar todos os passos através desta. Assim em uma eventual perda de conexão entre você e Exadata o patch continua a ser executado.

Recomenda-se criar uma pasta no dbnode, pode ser dentro da árvore /u01/patch. Copia-se o arquivo para tal destino e descompacta-se o mesmo. Como observado nas notas e no readme, não temos qualquer arquivo de fix para download.

Fazendo um merge de ambos os requisitos levantados optamos pelo patch em modo no-rolling. Neste caso é necessário parar toda a pilha do grid que roda sobre os dbnodes, assim paramos qualquer I/O. Para evitar qualquer problema, parei o Grid Control também (grid 12c já). Um esclarecimento, os agentes do grid não estão instalados nos storage nodes, eles são monitorados pelos agentes instalados dentro dos dbnodes:

/u01/app/oracle/product/12.1.0.1.0/core/12.1.0.1.0/bin/emctl stop agent

Desabilitando o agente do startup em todos os nós (já preparando para o patch dos dbnodes):

/sbin/chkconfig gcstartup off

Importante verificar se existe algum disco que não esteja com o status correto, se estiver em algum modo diferente de NORMAL o rebalanceamento deve ser concluído antes de prosseguir:

SQL> SELECT group_number, state, count(*) FROM v$asm_disk GROUP BY group_number, state;

GROUP_NUMBER STATE      COUNT(*)
------------ -------- ----------
           1 NORMAL           84
           2 NORMAL           84
           3 NORMAL           70

SQL> exit

Após isso, a pilha do grid deve ser parada e desabilitada (executado em ambos os dbnodes):

crsctl stop crs

crsctl disable crs

A aplicação do patch inicia com um shutdown de todos os serviços do Exadata nos storages. Mesmo que o software do Exadata seja iniciado em passos posteriores, ele é importante por garantir uma finalização limpa de ambiente. Este comando é executado em paralelo em todas as células através do dcli, e chamado de um dbnode:

[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root "cellcli -e alter cell shutdown services all"
exacel01: 
exacel01: Stopping the RS, CELLSRV, and MS services...
exacel01: The SHUTDOWN of services was successful.
exacel02: 
exacel02: Stopping the RS, CELLSRV, and MS services...
exacel02: The SHUTDOWN of services was successful.
exacel03: 
exacel03: Stopping the RS, CELLSRV, and MS services...
exacel03: The SHUTDOWN of services was successful.
exacel04: 
exacel04: Stopping the RS, CELLSRV, and MS services...
exacel04: The SHUTDOWN of services was successful.
exacel05: 
exacel05: Stopping the RS, CELLSRV, and MS services...
exacel05: The SHUTDOWN of services was successful.
exacel06: 
exacel06: Stopping the RS, CELLSRV, and MS services...
exacel06: The SHUTDOWN of services was successful.
exacel07: 
exacel07: Stopping the RS, CELLSRV, and MS services...
exacel07: The SHUTDOWN of services was successful.
[root@exadb01 patch_11.2.3.1.1.120607]#

Na atualização dos storage nodes utiliza-se o aplicativo patchmgr, este aplicativo é provido pelo próprio patch e realiza todo o trabalho sujo. É ele que copia todos os arquivos aos seus destinos e executa infinitos comandos de checagem e configuração. Caso você esteja partindo de versões antigas do storage node pode ser interessante aplicar o patch em um nó primeiro e em caso de sucesso passar aos outros. No caso de uma falha você pode cancelar a atualização dos outros nós e reverter (bare metal ou rollback) de só uma célula.

Após o shutdown, recomenda-se um cleanup em todos os storage nodes. Isso elimina qualquer vestígio de patchs anteriores como arquivos de configuração ou log. Novamente tudo chamado através do dbnode via dcli:

[root@exadb01 patch_11.2.3.1.1.120607]# ./patchmgr -cells cell_group -cleanup
Linux exadb01.tjsc.jus.br 2.6.18-194.3.1.0.4.el5 #1 SMP Sat Feb 19 03:38:37 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

2012-07-14 12:38:44 : DONE: Cleanup

[root@exadb01 patch_11.2.3.1.1.120607]#

Concluído o cleanup o patch_check_precheck do patch pode ser executado. Este precheck é importante por fazer uma varredura nos storage nodes e verificar qualquer inconsistência. Como os anteriores, chamado via um dbnode com o dcli:

[root@exadb01 patch_11.2.3.1.1.120607]# ./patchmgr -cells cell_group -patch_check_prereq
Linux exadb01.tjsc.jus.br 2.6.18-194.3.1.0.4.el5 #1 SMP Sat Feb 19 03:38:37 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

2012-07-14 12:39:15        :Working: DO: Check cells have ssh equivalence for root user. Up to 10 seconds per cell ...
2012-07-14 12:39:18        :SUCCESS: DONE: Check cells have ssh equivalence for root user.
2012-07-14 12:39:18        :Working: DO: Check space and state of Cell services on target cells. Up to 1 minute ...
2012-07-14 12:40:05        :SUCCESS: DONE: Check space and state of Cell services on target cells.
2012-07-14 12:40:05        :Working: DO: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction. Up to 40 minutes ...
2012-07-14 12:40:19 Wait correction of degraded md11 due to md partner size mismatch. Up to 30 minutes.

2012-07-14 12:40:22        :SUCCESS: DONE: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction.
2012-07-14 12:40:22        :Working: DO: Check prerequisites on all cells. Up to 2 minutes ...
2012-07-14 12:40:52        :SUCCESS: DONE: Check prerequisites on all cells.

[root@exadb01 patch_11.2.3.1.1.120607]#

Com o sucesso do precheck, devemos aplicar o patch com o patchmgr. Se você observar o log verá que a aplicação do patch executa também um precheck, de qualquer forma a chamada manual do precheck é importante para levantar qualquer problema que não tenha sido identificado anteriormente. Novamente o comando é executado através de um dbnode via dcli:

[root@exadb01 patch_11.2.3.1.1.120607]# ./patchmgr -cells cell_group -patch
Linux exadb01.tjsc.jus.br 2.6.18-194.3.1.0.4.el5 #1 SMP Sat Feb 19 03:38:37 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
NOTE Cells will reboot during the patch or rollback process.
NOTE For non-rolling patch or rollback, ensure all ASM instances using
NOTE the cells are shut down for the duration of the patch or rollback.
NOTE For rolling patch or rollback, ensure all ASM instances using
NOTE the cells are up for the duration of the patch or rollback.

WARNING Do not start more than one instance of patchmgr.
WARNING Do not interrupt the patchmgr session.
WARNING Do not alter state of ASM instances during patch or rollback.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot cells or alter cell services during patch or rollback.
WARNING Do not open log files in editor in write mode or try to alter them.

NOTE All time estimates are approximate. Timestamps on the left are real.
NOTE You may interrupt this patchmgr run in next 60 seconds with control-c.

2012-07-14 14:40:40        :Working: DO: Check cells have ssh equivalence for root user. Up to 10 seconds per cell ...
2012-07-14 14:40:44        :SUCCESS: DONE: Check cells have ssh equivalence for root user.
2012-07-14 14:40:44        :Working: DO: Check space and state of Cell services on target cells. Up to 1 minute ...
2012-07-14 14:41:31        :SUCCESS: DONE: Check space and state of Cell services on target cells.
2012-07-14 14:41:31        :Working: DO: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction. Up to 40 minutes ...
2012-07-14 14:41:45 Wait correction of degraded md11 due to md partner size mismatch. Up to 30 minutes.

2012-07-14 14:41:48        :SUCCESS: DONE: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction.
2012-07-14 14:41:48        :Working: DO: Check prerequisites on all cells. Up to 2 minutes ...
2012-07-14 14:42:17        :SUCCESS: DONE: Check prerequisites on all cells.
2012-07-14 14:42:17        :Working: DO: Copy the patch to all cells. Up to 3 minutes ...
2012-07-14 14:43:38        :SUCCESS: DONE: Copy the patch to all cells.
2012-07-14 14:43:40 1 of 5 :Working: DO: Initiate patch on cells. Cells will remain up. Up to 5 minutes ...
2012-07-14 14:43:43 1 of 5 :SUCCESS: DONE: Initiate patch on cells.
2012-07-14 14:43:43 2 of 5 :Working: DO: Waiting to finish pre-reboot patch actions. Cells will remain up. Up to 45 minutes ...
2012-07-14 14:44:43 Wait for patch pre-reboot procedures

2012-07-14 14:55:12 2 of 5 :SUCCESS: DONE: Waiting to finish pre-reboot patch actions.
2012-07-14 14:55:12 3 of 5 :Working: DO: Finalize patch on cells. Cells will reboot. Up to 5 minutes ...
2012-07-14 14:55:29 3 of 5 :SUCCESS: DONE: Finalize patch on cells.
2012-07-14 14:55:29 4 of 5 :Working: DO: Wait for cells to reboot and come online. Up to 120 minutes ...
2012-07-14 14:56:29 Wait for patch finalization and reboot

2012-07-14 16:30:22 4 of 5 :SUCCESS: DONE: Wait for cells to reboot and come online.
2012-07-14 16:30:22 5 of 5 :Working: DO: Check the state of patch on cells. Up to 5 minutes ...
2012-07-14 16:30:32 5 of 5 :SUCCESS: DONE: Check the state of patch on cells.

[root@exadb01 patch_11.2.3.1.1.120607]#

Infelizmente nem tudo são flores e um problema atormentou a atualização. Logo no início da atualização em um dos passos alguns devices são checados enquanto o patch continua, algumas coisas ocorrem de maneira assíncrona. Por um problema, identificado através da issue 1 do readme, alguns devices ficam bloqueados e forçam o cancelamento da aplicação do patch e seu rollback em todos os nós. Felizmente isso ocorre logo no início enquanto o arquivo com a imagem é copiado para as células, por isso o rollback é simples.

Como descrito no readme não existe solução para tal problema e ao indagar a equipe de desenvolvimento a resposta foi um “tenta até que funciona”. Antes de tentar novamente é importante rodar um cleanup. E após umas 10 tentativas (e duas horas depois) de falhas em nós aleatórios o patch iniciou com sucesso.

Durante a aplicação do patch você não tem controle de nada, tudo ocorre de forma automática. A imagem é copiada para as células, o nó é reiniciado, os firmwares são atualizados, alguns reboots ocorrem e a célula é liberada.

Um detalhe importante é que a aplicação do patch no storage node é um simples deploy de uma imagem. Se você observar um storage node, o software do Exadata bem como o Linux estão em partições. O que patch faz é copiar a imagem com a nova versão em duas partições antigas (uma para o Linux e outra para o software) mudar o grub para apontar para esta nova partição. Em caso de sucesso, o patch marca essa nova partição como ativa e inativa a anterior. No caso de um rollback, basta mudar o grub para anterior e reativá-la. Interessante não é?

Após o patch ter sido aplicado com sucesso é importante verificar se as imagens estão corretas. Isso pode ser observado através do imageinfo executado em ambos os storage nodes. Novamente tudo pode ser executado através do dbnode via dcli:

[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root imageinfo
exacel01:
exacel01:
exacel01: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64
exacel01: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607
exacel01: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1
exacel01:
exacel01: Active image version: 11.2.3.1.1.120607
exacel01: Active image activated: 2012-07-14 15:51:10 -0300
exacel01: Active image status: success
exacel01: Active system partition on device: /dev/md6
exacel01: Active software partition on device: /dev/md8
exacel01:
exacel01: In partition rollback: Impossible
exacel01:
exacel01: Cell boot usb partition: /dev/sdm1
exacel01: Cell boot usb version: 11.2.3.1.1.120607
exacel01:
exacel01: Inactive image version: 11.2.2.3.5.110815
exacel01: Inactive image activated: 2011-09-24 04:02:31 -0300
exacel01: Inactive image status: success
exacel01: Inactive system partition on device: /dev/md5
exacel01: Inactive software partition on device: /dev/md7
exacel01:
exacel01: Boot area has rollback archive for the version: 11.2.2.3.5.110815
exacel01: Rollback to the inactive partitions: Possible
exacel02:
exacel02:
exacel02: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64
exacel02: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607
exacel02: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1
exacel02:
exacel02: Active image version: 11.2.3.1.1.120607
exacel02: Active image activated: 2012-07-14 16:29:39 -0300
exacel02: Active image status: success
exacel02: Active system partition on device: /dev/md5
exacel02: Active software partition on device: /dev/md7
exacel02:
exacel02: In partition rollback: Impossible
exacel02:
exacel02: Cell boot usb partition: /dev/sdm1
exacel02: Cell boot usb version: 11.2.3.1.1.120607
exacel02:
exacel02: Inactive image version: 11.2.1.3.1
exacel02: Inactive image activated: 2012-03-21 15:28:37 -0300
exacel02: Inactive image status: success
exacel02: Inactive system partition on device: /dev/md6
exacel02: Inactive software partition on device: /dev/md8
exacel02:
exacel02: Boot area has rollback archive for the version: 11.2.1.3.1
exacel02: Rollback to the inactive partitions: Possible
exacel03:
exacel03:
exacel03: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64
exacel03: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607
exacel03: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1
exacel03:
exacel03: Active image version: 11.2.3.1.1.120607
exacel03: Active image activated: 2012-07-14 15:52:57 -0300
exacel03: Active image status: success
exacel03: Active system partition on device: /dev/md6
exacel03: Active software partition on device: /dev/md8
exacel03:
exacel03: In partition rollback: Impossible
exacel03:
exacel03: Cell boot usb partition: /dev/sdm1
exacel03: Cell boot usb version: 11.2.3.1.1.120607
exacel03:
exacel03: Inactive image version: 11.2.2.3.5.110815
exacel03: Inactive image activated: 2011-09-24 04:02:32 -0300
exacel03: Inactive image status: success
exacel03: Inactive system partition on device: /dev/md5
exacel03: Inactive software partition on device: /dev/md7
exacel03:
exacel03: Boot area has rollback archive for the version: 11.2.2.3.5.110815
exacel03: Rollback to the inactive partitions: Possible
exacel04:
exacel04:
exacel04: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64
exacel04: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607
exacel04: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1
exacel04:
exacel04: Active image version: 11.2.3.1.1.120607
exacel04: Active image activated: 2012-07-14 15:50:46 -0300
exacel04: Active image status: success
exacel04: Active system partition on device: /dev/md6
exacel04: Active software partition on device: /dev/md8
exacel04:
exacel04: In partition rollback: Impossible
exacel04:
exacel04: Cell boot usb partition: /dev/sdm1
exacel04: Cell boot usb version: 11.2.3.1.1.120607
exacel04:
exacel04: Inactive image version: 11.2.2.3.5.110815
exacel04: Inactive image activated: 2011-09-24 04:02:32 -0300
exacel04: Inactive image status: success
exacel04: Inactive system partition on device: /dev/md5
exacel04: Inactive software partition on device: /dev/md7
exacel04:
exacel04: Boot area has rollback archive for the version: 11.2.2.3.5.110815
exacel04: Rollback to the inactive partitions: Possible
exacel05:
exacel05:
exacel05: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64
exacel05: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607
exacel05: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1
exacel05:
exacel05: Active image version: 11.2.3.1.1.120607
exacel05: Active image activated: 2012-07-14 15:51:41 -0300
exacel05: Active image status: success
exacel05: Active system partition on device: /dev/md6
exacel05: Active software partition on device: /dev/md8
exacel05:
exacel05: In partition rollback: Impossible
exacel05:
exacel05: Cell boot usb partition: /dev/sdm1
exacel05: Cell boot usb version: 11.2.3.1.1.120607
exacel05:
exacel05: Inactive image version: 11.2.2.3.5.110815
exacel05: Inactive image activated: 2011-09-24 04:02:31 -0300
exacel05: Inactive image status: success
exacel05: Inactive system partition on device: /dev/md5
exacel05: Inactive software partition on device: /dev/md7
exacel05:
exacel05: Boot area has rollback archive for the version: 11.2.2.3.5.110815
exacel05: Rollback to the inactive partitions: Possible
exacel06:
exacel06:
exacel06: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64
exacel06: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607
exacel06: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1
exacel06:
exacel06: Active image version: 11.2.3.1.1.120607
exacel06: Active image activated: 2012-07-14 15:51:21 -0300
exacel06: Active image status: success
exacel06: Active system partition on device: /dev/md6
exacel06: Active software partition on device: /dev/md8
exacel06:
exacel06: In partition rollback: Impossible
exacel06:
exacel06: Cell boot usb partition: /dev/sdm1
exacel06: Cell boot usb version: 11.2.3.1.1.120607
exacel06:
exacel06: Inactive image version: 11.2.2.3.5.110815
exacel06: Inactive image activated: 2011-09-24 04:02:32 -0300
exacel06: Inactive image status: success
exacel06: Inactive system partition on device: /dev/md5
exacel06: Inactive software partition on device: /dev/md7
exacel06:
exacel06: Boot area has rollback archive for the version: 11.2.2.3.5.110815
exacel06: Rollback to the inactive partitions: Possible
exacel07:
exacel07:
exacel07: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64
exacel07: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607
exacel07: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1
exacel07:
exacel07: Active image version: 11.2.3.1.1.120607
exacel07: Active image activated: 2012-07-14 15:50:22 -0300
exacel07: Active image status: success
exacel07: Active system partition on device: /dev/md6
exacel07: Active software partition on device: /dev/md8
exacel07:
exacel07: In partition rollback: Impossible
exacel07:
exacel07: Cell boot usb partition: /dev/sdm1
exacel07: Cell boot usb version: 11.2.3.1.1.120607
exacel07:
exacel07: Inactive image version: 11.2.2.3.5.110815
exacel07: Inactive image activated: 2011-09-24 04:02:31 -0300
exacel07: Inactive image status: success
exacel07: Inactive system partition on device: /dev/md5
exacel07: Inactive software partition on device: /dev/md7
exacel07:
exacel07: Boot area has rollback archive for the version: 11.2.2.3.5.110815
exacel07: Rollback to the inactive partitions: Possible
[root@exadb01 patch_11.2.3.1.1.120607]#
[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root imageinfo|grep "Active image version"
exacel01: Active image version: 11.2.3.1.1.120607
exacel02: Active image version: 11.2.3.1.1.120607
exacel03: Active image version: 11.2.3.1.1.120607
exacel04: Active image version: 11.2.3.1.1.120607
exacel05: Active image version: 11.2.3.1.1.120607
exacel06: Active image version: 11.2.3.1.1.120607
exacel07: Active image version: 11.2.3.1.1.120607
[root@exadb01 patch_11.2.3.1.1.120607]#
[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root imageinfo|grep "Active image status"
exacel01: Active image status: success
exacel02: Active image status: success
exacel03: Active image status: success
exacel04: Active image status: success
exacel05: Active image status: success
exacel06: Active image status: success
exacel07: Active image status: success
[root@exadb01 patch_11.2.3.1.1.120607]#

Como pode ser observado acima, existe uma versão rodando em uma partição e marcada como ativa. Enquanto existe outra marcada como inativa em outra versão.

Após isso, deve-se verificar de não ocorreram qualquer falha que pode estar listada nos logs do Exadata:

[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root grep -i fail /var/log/cellos/validations.log
exacel01:
exacel02:
exacel03:
exacel04:
exacel05:
exacel06:
exacel07:
[root@exadb01 patch_11.2.3.1.1.120607]#

Por fim, um cleanup em todos os storage nodes limpa qualquer arquivo indesejado:

[root@exadb01 patch_11.2.3.1.1.120607]# ./patchmgr -cells cell_group -cleanup
Linux exadb01.tjsc.jus.br 2.6.18-194.3.1.0.4.el5 #1 SMP Sat Feb 19 03:38:37 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

2012-07-14 16:38:11 : DONE: Cleanup

[root@exadb01 patch_11.2.3.1.1.120607]#

Um detalhe importante é que mesmo com um cleanup alguns arquivos podem sobrar. Um local a ser observado é o /boot do storage node (em todos). Verifique por arquivo ocultos (com nome sugestivo de rollback), se estes arquivos existirem ali em um eventual reboot o storage pode fazer um rollback de versão. Isso já aconteceu comigo e não é um procedimento legal. Se você observar nos logs do imageinfo acima vai observar que a célula #2 estava em uma versão diferente das demais.

Finalizando, a atualização do storage node é simples, na realidade é uma NNF. Não existe muito controle sobre o que é executado e os passos do processo. Importante é se cercar com o maior número de informações possíveis sobre o procedimento. Verificar todos os requisitos, vasculhar as notas associadas e identificar possíveis problemas. Se você tiver um Exadata de homologação aplique primeiro ali antes da produção. Prepare-se com antecedência, comece uma semana antes e revise todos os passos, escreva um manual (pode ser em papel mesmo) do que será feito e como será feito.

Se você estiver preparado as consequências dos erros podem ser minimizadas ou evitadas. Acho que não preciso nem citar, antes e depois de iniciar tudo faça um backup dos seus bancos e tenha um plano B. Para o próximo post a atualização do dbnode.