Um dos pontos que sempre perguntam sobre o Exadata \u00e9 sobre a sua atualiza\u00e7\u00e3o, como ela \u00e9 ou pode ser atualizado? Como o seu storage \u00e9 atualizado? Realmente, e sendo franco, a sua atualiza\u00e7\u00e3o n\u00e3o \u00e9 uma das mais simples no universo Oracle.<\/p>\n
Simplificando, a sua atualiza\u00e7\u00e3o pode ser dividida em duas partes, a primeira \u00e9 a atualiza\u00e7\u00e3o do software Exadata que roda nos storage nodes<\/em>. A segunda parte \u00e9 a atualiza\u00e7\u00e3o dos dbnodes<\/em>, e esta \u00faltima pode levar a mais algumas.<\/p>\n Desta forma, dividirei este post<\/em> em dois. Primeiro falando da atualiza\u00e7\u00e3o dos storage nodes<\/em>. E um segundo post falando da atualiza\u00e7\u00e3o dos dbnodes<\/em>.<\/p>\n Antes de come\u00e7ar a falar sobre a atualiza\u00e7\u00e3o em si \u00e9 importante saber onde voc\u00ea est\u00e1 indo. Tra\u00e7ar um mapa do que deve ser feito, dos passos importantes que ser\u00e3o tomados, das notas do Metalink<\/em> com as informa\u00e7\u00f5es importantes e dos contatos necess\u00e1rios.<\/p>\n <\/p>\n Se eu n\u00e3o me engano, atualmente no contrato de aquisi\u00e7\u00e3o j\u00e1 est\u00e3o embutidas horas de atualiza\u00e7\u00e3o do Exadata pela equipe Oracle Advanced Customer Support<\/em> (ACS), sendo horas para atualiza\u00e7\u00e3o a cada tr\u00eas ou quatro meses. De qualquer forma nada impede que a atualiza\u00e7\u00e3o do Exadata seja feita sem acompanhamento da equipe ACS, ou mesmo que eles estejam presentes que a atualiza\u00e7\u00e3o n\u00e3o seja feita por eles.<\/p>\n O profissional da ACS que estiver acompanhando a atualiza\u00e7\u00e3o servir\u00e1 de ponte entre voc\u00ea, a atualiza\u00e7\u00e3o e a equipe de desenvolvimento do Exadata Oracle. Caso ocorra um erro durante a atualiza\u00e7\u00e3o, ao voc\u00ea abrir a SR, o ACS presente poder\u00e1 intervir e priorizar o atendimento. A equipe de suporte da Oracle que est\u00e1 atendendo a SR saber\u00e1 que se o ACS presente n\u00e3o conseguiu resolver o problema, ele \u00e9 grande. Como pode ser notado, o fluxo \u00e9 o mesmo, a presen\u00e7a do ACS n\u00e3o desobriga abertura de um SR. Em caso de erro na atualiza\u00e7\u00e3o o \u00fanico caminho \u00e9 esse, abertura de SR e espera por reposta (mesmo com um ACS sentado ao seu lado).<\/p>\n Assim, voc\u00ea pode solicitar ao ACS presente que a atualiza\u00e7\u00e3o seja feita por voc\u00ea e n\u00e3o por ele, que ele acompanhe a sua atualiza\u00e7\u00e3o. Nos Estados Unidos \u00e9 comum este m\u00e9todo. Acredito que este tipo de trabalho seja interessante, pois existe a possibilidade de aprender diversas etapas que n\u00e3o s\u00e3o comuns na administra\u00e7\u00e3o do Exadata. No TJ o caso \u00e9 mais peculiar, por sermos o segundo Exadata no Brasil (primeiro OLTP e ainda um V2) comprado nos idos de 2010 n\u00e3o temos horas ACS dispon\u00edveis (isso n\u00e3o existia no contrato naquela \u00e9poca). Assim temos que fazer por n\u00f3s mesmo ou adquirir horas de suporte.<\/p>\n A atualiza\u00e7\u00e3o do Exadata \u00e9 liberada a cada quatro meses, assim temos tr\u00eas vers\u00f5es principais por ano. Estes patchs<\/em> s\u00e3o chamados de Quarterly Database Patch for Exadata<\/em> (QDPE) e incluem Critical Patch Update<\/em> (CPU) e Patch Set Update<\/em> (PSU) que foram homologados nos laborat\u00f3rios da Oracle. Em alguns casos especiais vers\u00f5es s\u00e3o lan\u00e7adas 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\u00edodo de menos de um m\u00eas, ou at\u00e9 mesmo da 11.2.2.3.1 que foi marcada como withdrawn<\/em> (tinha um bug no firmware da controladora que causava a perda dos discos).<\/p>\n A atualiza\u00e7\u00e3o do Exadata, do software presente no storage nodes<\/em> e dos dbnodes<\/em>, est\u00e1 contida em um \u00fanico arquivo. Assim, a atualiza\u00e7\u00e3o cont\u00eam as novas vers\u00f5es do software do Exadata, do kernel<\/em> do Linux (e seus pacotes), patchs<\/em> ou novas vers\u00f5es de firmwares<\/em> de discos e suas controladoras e ILOM. O patch<\/em> do Exadata n\u00e3o atualiza o switch Infiniband, este \u00e9 atualizado atrav\u00e9s de um pacote separado.<\/p>\n O ponto inicial para iniciar um projeto de atualiza\u00e7\u00e3o do Exadata \u00e9 come\u00e7ar pela nota 888828.1 do Metalink. Nesta nota existem informa\u00e7\u00f5es sobre as vers\u00f5es dispon\u00edveis, qual a \u00faltima lan\u00e7ada, e a compatibilidade entre elas. Uma informa\u00e7\u00e3o importante contida l\u00e1 \u00e9 sobre a vers\u00e3o do kernel<\/em> do Linux presente nas vers\u00f5es do Exadata.<\/p>\n A vers\u00e3o do kernel<\/em> \u00e9 importante, pois \u00e9 necess\u00e1rio manter as vers\u00f5es do dbnode<\/em> e storage node<\/em> compat\u00edveis no mesmo kernel<\/em>.\u00a0 Vers\u00e3o diferentes n\u00e3o s\u00e3o comuns, mas no caso de um rollback for\u00e7ado de vers\u00e3o podemos ter incompatibilidade com o OFED. Resumindo, o OFED \u00e9 o driver<\/em>\/software de acesso a Infiniband provido pela Oracle e ele est\u00e1 intimamente ao kernel<\/em> e ao software do Exadata.<\/p>\n Atrav\u00e9s desta nota podemos tra\u00e7ar o projeto da atualiza\u00e7\u00e3o, identificar as notas espec\u00edficas da vers\u00e3o desejadas e as critical issues<\/em> que podem ocorrer. Neste caso, estamos atualizando para a vers\u00e3o 11.2.3.1.1 (que \u00e9 \u00faltima at\u00e9 a data atual) e a nota sobre esta vers\u00e3o \u00e9 a 1466459.1.\u00a0 No meu caso, estou saindo da 11.2.2.3.5 para a \u00faltima.<\/p>\n Com base no hist\u00f3rico de atualiza\u00e7\u00f5es j\u00e1 aplicadas aqui e com base nas notas alguns pontos devem ser verificados antes de come\u00e7ar o patch<\/em> em si:<\/p>\n Estas s\u00e3o as linhas gerais que podem ser observadas e influenciar o patch<\/em>. Pode ser que n\u00e3o seja poss\u00edvel parar o backup em um final de semana espec\u00edfico por exemplo, ou o GRID necessite ficar online, ou at\u00e9 mesmo uma issue<\/em> n\u00e3o resolvida entre o banco e o software do Exadata que seja imprescind\u00edvel no seu ambiente.<\/p>\n Avan\u00e7ando um pouco mais, temos a atualiza\u00e7\u00e3o dos storage nodes<\/em>. Como citei, estamos indo para a \u00faltima vers\u00e3o, presente no patch<\/em> 13998727 e descrito na nota 1466459.1. Apesar da exist\u00eancia desta nota, o manual a ser seguido \u00e9 o readme <\/em>que acompanha o patch.<\/em> As informa\u00e7\u00f5es contidas ali s\u00e3o muito mais detalhadas que qualquer nota do Metalink.<\/p>\n Novamente \u00e9 importante tra\u00e7ar um passo a passo do que ser\u00e1 feito, identificando qualquer problema que possa surgir. Com base em experi\u00eancias anteriores, nas notas e no readme<\/em> associado acho importante:<\/p>\n Algo que notei durante o patch<\/em> foi com a ILOM, j\u00e1 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 \u00e9 um bug (corrigido na \u00faltima vers\u00e3o) presente na ILOM. O detalhe aqui \u00e9 que o patch<\/em> disparado tem um timeout para considerar se n\u00e3o houve erro, esse timeout \u00e9 curto e o patch<\/em> entende que a demora foi causada por um erro na sua aplica\u00e7\u00e3o e cancela tudo, fazendo rollback<\/em> de tudo em todos os n\u00f3s. Como isso n\u00e3o \u00e9 legal recomendo reiniciar todas as ILOM\u2019s (de todos os n\u00f3s e dbnodes<\/em>), bem como um reboot geral do seu Exadata antes de iniciar tudo, parece estranho (e \u00e9) mas pode evitar problemas. Isso est\u00e1 listado nas entrelinhas do issue<\/em> 6 do readme <\/em>do patch<\/em>.<\/p>\n Antes de aplicar o patch<\/em> acho importante definir os passos que ser\u00e3o realizados, a nota do patch<\/em> e seu readme <\/em>s\u00e3o extensos e criar um passo a passo julgo ser fundamental. Na aplica\u00e7\u00e3o deste patch<\/em> os passos que mapeados foram:<\/p>\n Com os passos mapeados podemos prosseguir com a aplica\u00e7\u00e3o do patch<\/em>. Partindo de um download do patch<\/em> diretamente do Metalink temos que copi\u00e1-lo para um dbnode<\/em>. A aplica\u00e7\u00e3o do patch<\/em> n\u00e3o \u00e9 chamada diretamente no storage node<\/em>, o patch<\/em> reside no dbnode<\/em> e \u00e9 aplicado nos storages. Por isso, \u00e9 necess\u00e1rio que exista a equival\u00eancia de ssh para root entre todos os servidores do Exadata. Al\u00e9m disso, deve-se iniciar uma se\u00e7\u00e3o VNC com o dbnode<\/em> e realizar todos os passos atrav\u00e9s desta. Assim em uma eventual perda de conex\u00e3o entre voc\u00ea e Exadata o patch<\/em> continua a ser executado.<\/p>\n Recomenda-se criar uma pasta no dbnode<\/em>, pode ser dentro da \u00e1rvore \/u01\/patch<\/em>. Copia-se o arquivo para tal destino e descompacta-se o mesmo. Como observado nas notas e no readme<\/em>, n\u00e3o temos qualquer arquivo de fix<\/em> para download.<\/p>\n Fazendo um merge de ambos os requisitos levantados optamos pelo patch<\/em> em modo no-rolling<\/em>. Neste caso \u00e9 necess\u00e1rio parar toda a pilha do grid que roda sobre os dbnodes,\u00a0a<\/em>ssim paramos qualquer I\/O. Para evitar qualquer problema, parei o Grid Control tamb\u00e9m (grid 12c j\u00e1). Um esclarecimento, os agentes do grid n\u00e3o est\u00e3o instalados nos storage nodes<\/em>, eles s\u00e3o monitorados pelos agentes instalados dentro dos dbnodes<\/em>:<\/p>\n Desabilitando o agente do startup em todos os n\u00f3s (j\u00e1 preparando para o patch<\/em> dos dbnodes<\/em>):<\/p>\n Importante verificar se existe algum disco que n\u00e3o esteja com o status correto, se estiver em algum modo diferente de NORMAL o rebalanceamento deve ser conclu\u00eddo antes de prosseguir:<\/p>\n Ap\u00f3s isso, a pilha do grid deve ser parada e desabilitada (executado em ambos os dbnodes<\/em>):<\/p>\n A aplica\u00e7\u00e3o do patch<\/em> inicia com um shutdown de todos os servi\u00e7os do Exadata nos storages. Mesmo que o software do Exadata seja iniciado em passos posteriores, ele \u00e9 importante por garantir uma finaliza\u00e7\u00e3o limpa de ambiente. Este comando \u00e9 executado em paralelo em todas as c\u00e9lulas atrav\u00e9s do dcli, e chamado de um dbnode<\/em>:<\/p>\n Na atualiza\u00e7\u00e3o dos storage nodes<\/em> utiliza-se o aplicativo patchmgr<\/strong>, este aplicativo \u00e9 provido pelo pr\u00f3prio patch<\/em> e realiza todo o trabalho sujo. \u00c9 ele que copia todos os arquivos aos seus destinos e executa infinitos comandos de checagem e configura\u00e7\u00e3o. Caso voc\u00ea esteja partindo de vers\u00f5es antigas do storage node<\/em> pode ser interessante aplicar o patch<\/em> em um n\u00f3 primeiro e em caso de sucesso passar aos outros. No caso de uma falha voc\u00ea pode cancelar a atualiza\u00e7\u00e3o dos outros n\u00f3s e reverter (bare metal ou rollback) de s\u00f3 uma c\u00e9lula.<\/p>\n Ap\u00f3s o shutdown, recomenda-se um cleanup<\/strong> em todos os storage nodes<\/em>. Isso elimina qualquer vest\u00edgio de patchs<\/em> anteriores como arquivos de configura\u00e7\u00e3o ou log. Novamente tudo chamado atrav\u00e9s do dbnode<\/em> via dcli:<\/p>\n Conclu\u00eddo o cleanup<\/strong> o patch_check_precheck<\/strong> do patch<\/em> pode ser executado. Este precheck<\/em> \u00e9 importante por fazer uma varredura nos storage nodes<\/em> e verificar qualquer inconsist\u00eancia. Como os anteriores, chamado via um dbnode com o dcli:<\/p>\n Com o sucesso do precheck<\/em>, devemos aplicar o patch<\/em> com o patchmgr<\/strong>. Se voc\u00ea observar o log ver\u00e1 que a aplica\u00e7\u00e3o do patch<\/em> executa tamb\u00e9m um precheck, de qualquer forma a chamada manual do precheck<\/em> \u00e9 importante para levantar qualquer problema que n\u00e3o tenha sido identificado anteriormente. Novamente o comando \u00e9 executado atrav\u00e9s de um dbnode<\/em> via dcli:<\/p>\n Infelizmente nem tudo s\u00e3o flores e um problema atormentou a atualiza\u00e7\u00e3o. Logo no in\u00edcio da atualiza\u00e7\u00e3o em um dos passos alguns devices<\/em> s\u00e3o checados enquanto o patch<\/em> continua, algumas coisas ocorrem de maneira ass\u00edncrona. Por um problema, identificado atrav\u00e9s da issue <\/em>1 do readme<\/em>, alguns devices<\/em> ficam bloqueados e for\u00e7am o cancelamento da aplica\u00e7\u00e3o do patch<\/em> e seu rollback\u00a0<\/em>em todos os n\u00f3s. Felizmente isso ocorre logo no in\u00edcio enquanto o arquivo com a imagem \u00e9 copiado para as c\u00e9lulas, por isso o rollback \u00e9 simples.<\/p>\n Como descrito no readme<\/em> n\u00e3o existe solu\u00e7\u00e3o para tal problema e ao indagar a equipe de desenvolvimento a resposta foi um \u201ctenta at\u00e9 que funciona\u201d. Antes de tentar novamente \u00e9 importante rodar um cleanup<\/em>. E ap\u00f3s umas 10 tentativas (e duas horas depois) de falhas em n\u00f3s aleat\u00f3rios o patch<\/em> iniciou com sucesso.<\/p>\n Durante a aplica\u00e7\u00e3o do patch<\/em> voc\u00ea n\u00e3o tem controle de nada, tudo ocorre de forma autom\u00e1tica. A imagem \u00e9 copiada para as c\u00e9lulas, o n\u00f3 \u00e9 reiniciado, os firmwares<\/em> s\u00e3o atualizados, alguns reboots ocorrem e a c\u00e9lula \u00e9 liberada.<\/p>\n Um detalhe importante \u00e9 que a aplica\u00e7\u00e3o do patch<\/em> no storage node<\/em> \u00e9 um simples deploy<\/em> de uma imagem. Se voc\u00ea observar um storage node<\/em>, o software do Exadata bem como o Linux est\u00e3o em parti\u00e7\u00f5es. O que patch<\/em> faz \u00e9 copiar a imagem com a nova vers\u00e3o em duas parti\u00e7\u00f5es antigas (uma para o Linux e outra para o software) mudar o grub<\/em><\/strong> para apontar para esta nova parti\u00e7\u00e3o. Em caso de sucesso, o patch<\/em> marca essa nova parti\u00e7\u00e3o como ativa e inativa a anterior. No caso de um rollback<\/em>, basta mudar o grub<\/em><\/strong> para anterior e reativ\u00e1-la. Interessante n\u00e3o \u00e9?<\/p>\n Ap\u00f3s o patch<\/em> ter sido aplicado com sucesso \u00e9 importante verificar se as imagens est\u00e3o corretas. Isso pode ser observado atrav\u00e9s do imageinfo<\/strong> executado em ambos os storage nodes<\/em>. Novamente tudo pode ser executado atrav\u00e9s do dbnode<\/em> via dcli:<\/p>\n Como pode ser observado acima, existe uma vers\u00e3o rodando em uma parti\u00e7\u00e3o e marcada como ativa. Enquanto existe outra marcada como inativa em outra vers\u00e3o.<\/p>\n Ap\u00f3s isso, deve-se verificar de n\u00e3o ocorreram qualquer falha que pode estar listada nos logs do Exadata:<\/p>\n Por fim, um cleanup<\/em> em todos os storage nodes<\/em> limpa qualquer arquivo indesejado:<\/p>\n Um detalhe importante \u00e9 que mesmo com um cleanup<\/em> alguns arquivos podem sobrar. Um local a ser observado \u00e9 o \/boot<\/strong> do storage node<\/em> (em todos). Verifique por arquivo ocultos (com nome sugestivo de rollback<\/em>), se estes arquivos existirem ali em um eventual reboot o storage pode fazer um rollback<\/em> de vers\u00e3o. Isso j\u00e1 aconteceu comigo e n\u00e3o \u00e9 um procedimento legal. Se voc\u00ea observar nos logs do imageinfo<\/em> acima vai observar que a c\u00e9lula #2 estava em uma vers\u00e3o diferente das demais.<\/p>\n Finalizando, a atualiza\u00e7\u00e3o do storage node<\/em> \u00e9 simples, na realidade \u00e9 uma NNF. N\u00e3o existe muito controle sobre o que \u00e9 executado e os passos do processo. Importante \u00e9 se cercar com o maior n\u00famero de informa\u00e7\u00f5es poss\u00edveis sobre o procedimento. Verificar todos os requisitos, vasculhar as notas associadas e identificar poss\u00edveis problemas. Se voc\u00ea tiver um Exadata de homologa\u00e7\u00e3o aplique primeiro ali antes da produ\u00e7\u00e3o. Prepare-se com anteced\u00eancia, comece uma semana antes e revise todos os passos, escreva um manual (pode ser em papel mesmo) do que ser\u00e1 feito e como ser\u00e1 feito.<\/p>\n Se voc\u00ea estiver preparado as consequ\u00eancias dos erros podem ser minimizadas ou evitadas. Acho que n\u00e3o preciso nem citar, antes e depois de iniciar tudo fa\u00e7a um backup dos seus bancos e tenha um plano B. Para o pr\u00f3ximo post<\/em> a atualiza\u00e7\u00e3o do dbnode<\/em>.<\/p>\n","protected":false},"excerpt":{"rendered":" Um dos pontos que sempre perguntam sobre o Exadata \u00e9 sobre a sua atualiza\u00e7\u00e3o, como ela \u00e9 ou pode ser atualizado? Como o seu storage \u00e9 atualizado? Realmente, e sendo franco, a sua atualiza\u00e7\u00e3o n\u00e3o \u00e9 uma das mais simples no universo Oracle. Simplificando, a sua atualiza\u00e7\u00e3o pode ser dividida em duas partes, a primeira […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[6,13,9,14,12],"tags":[],"class_list":["post-49","post","type-post","status-publish","format-standard","hentry","category-exadata","category-patchmgr","category-storage-server","category-update","category-upgrade"],"yoast_head":"\n\n
\n
\n
\/u01\/app\/oracle\/product\/12.1.0.1.0\/core\/12.1.0.1.0\/bin\/emctl stop agent<\/pre>\n
\/sbin\/chkconfig gcstartup off<\/pre>\n
SQL> SELECT group_number, state, count(*) FROM v$asm_disk GROUP BY group_number, state;\r\n\r\nGROUP_NUMBER STATE COUNT(*)\r\n------------ -------- ----------\r\n 1 NORMAL 84\r\n 2 NORMAL 84\r\n 3 NORMAL 70\r\n\r\nSQL> exit<\/pre>\n
crsctl stop crs<\/pre>\n
crsctl disable crs<\/pre>\n
[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root \"cellcli -e alter cell shutdown services all\"\r\nexacel01: \r\nexacel01: Stopping the RS, CELLSRV, and MS services...\r\nexacel01: The SHUTDOWN of services was successful.\r\nexacel02: \r\nexacel02: Stopping the RS, CELLSRV, and MS services...\r\nexacel02: The SHUTDOWN of services was successful.\r\nexacel03: \r\nexacel03: Stopping the RS, CELLSRV, and MS services...\r\nexacel03: The SHUTDOWN of services was successful.\r\nexacel04: \r\nexacel04: Stopping the RS, CELLSRV, and MS services...\r\nexacel04: The SHUTDOWN of services was successful.\r\nexacel05: \r\nexacel05: Stopping the RS, CELLSRV, and MS services...\r\nexacel05: The SHUTDOWN of services was successful.\r\nexacel06: \r\nexacel06: Stopping the RS, CELLSRV, and MS services...\r\nexacel06: The SHUTDOWN of services was successful.\r\nexacel07: \r\nexacel07: Stopping the RS, CELLSRV, and MS services...\r\nexacel07: The SHUTDOWN of services was successful.\r\n[root@exadb01 patch_11.2.3.1.1.120607]#<\/pre>\n
[root@exadb01 patch_11.2.3.1.1.120607]# .\/patchmgr -cells cell_group -cleanup\r\nLinux 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\r\n\r\n2012-07-14 12:38:44 : DONE: Cleanup\r\n\r\n[root@exadb01 patch_11.2.3.1.1.120607]#<\/pre>\n
[root@exadb01 patch_11.2.3.1.1.120607]# .\/patchmgr -cells cell_group -patch_check_prereq\r\nLinux 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\r\n\r\n2012-07-14 12:39:15 :Working: DO: Check cells have ssh equivalence for root user. Up to 10 seconds per cell ...\r\n2012-07-14 12:39:18 :SUCCESS: DONE: Check cells have ssh equivalence for root user.\r\n2012-07-14 12:39:18 :Working: DO: Check space and state of Cell services on target cells. Up to 1 minute ...\r\n2012-07-14 12:40:05 :SUCCESS: DONE: Check space and state of Cell services on target cells.\r\n2012-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 ...\r\n2012-07-14 12:40:19 Wait correction of degraded md11 due to md partner size mismatch. Up to 30 minutes.\r\n\r\n2012-07-14 12:40:22 :SUCCESS: DONE: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction.\r\n2012-07-14 12:40:22 :Working: DO: Check prerequisites on all cells. Up to 2 minutes ...\r\n2012-07-14 12:40:52 :SUCCESS: DONE: Check prerequisites on all cells.\r\n\r\n[root@exadb01 patch_11.2.3.1.1.120607]#<\/pre>\n
[root@exadb01 patch_11.2.3.1.1.120607]# .\/patchmgr -cells cell_group -patch\r\nLinux 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\r\nNOTE Cells will reboot during the patch or rollback process.\r\nNOTE For non-rolling patch or rollback, ensure all ASM instances using\r\nNOTE the cells are shut down for the duration of the patch or rollback.\r\nNOTE For rolling patch or rollback, ensure all ASM instances using\r\nNOTE the cells are up for the duration of the patch or rollback.\r\n\r\nWARNING Do not start more than one instance of patchmgr.\r\nWARNING Do not interrupt the patchmgr session.\r\nWARNING Do not alter state of ASM instances during patch or rollback.\r\nWARNING Do not resize the screen. It may disturb the screen layout.\r\nWARNING Do not reboot cells or alter cell services during patch or rollback.\r\nWARNING Do not open log files in editor in write mode or try to alter them.\r\n\r\nNOTE All time estimates are approximate. Timestamps on the left are real.\r\nNOTE You may interrupt this patchmgr run in next 60 seconds with control-c.\r\n\r\n2012-07-14 14:40:40 :Working: DO: Check cells have ssh equivalence for root user. Up to 10 seconds per cell ...\r\n2012-07-14 14:40:44 :SUCCESS: DONE: Check cells have ssh equivalence for root user.\r\n2012-07-14 14:40:44 :Working: DO: Check space and state of Cell services on target cells. Up to 1 minute ...\r\n2012-07-14 14:41:31 :SUCCESS: DONE: Check space and state of Cell services on target cells.\r\n2012-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 ...\r\n2012-07-14 14:41:45 Wait correction of degraded md11 due to md partner size mismatch. Up to 30 minutes.\r\n\r\n2012-07-14 14:41:48 :SUCCESS: DONE: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction.\r\n2012-07-14 14:41:48 :Working: DO: Check prerequisites on all cells. Up to 2 minutes ...\r\n2012-07-14 14:42:17 :SUCCESS: DONE: Check prerequisites on all cells.\r\n2012-07-14 14:42:17 :Working: DO: Copy the patch to all cells. Up to 3 minutes ...\r\n2012-07-14 14:43:38 :SUCCESS: DONE: Copy the patch to all cells.\r\n2012-07-14 14:43:40 1 of 5 :Working: DO: Initiate patch on cells. Cells will remain up. Up to 5 minutes ...\r\n2012-07-14 14:43:43 1 of 5 :SUCCESS: DONE: Initiate patch on cells.\r\n2012-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 ...\r\n2012-07-14 14:44:43 Wait for patch pre-reboot procedures\r\n\r\n2012-07-14 14:55:12 2 of 5 :SUCCESS: DONE: Waiting to finish pre-reboot patch actions.\r\n2012-07-14 14:55:12 3 of 5 :Working: DO: Finalize patch on cells. Cells will reboot. Up to 5 minutes ...\r\n2012-07-14 14:55:29 3 of 5 :SUCCESS: DONE: Finalize patch on cells.\r\n2012-07-14 14:55:29 4 of 5 :Working: DO: Wait for cells to reboot and come online. Up to 120 minutes ...\r\n2012-07-14 14:56:29 Wait for patch finalization and reboot\r\n\r\n2012-07-14 16:30:22 4 of 5 :SUCCESS: DONE: Wait for cells to reboot and come online.\r\n2012-07-14 16:30:22 5 of 5 :Working: DO: Check the state of patch on cells. Up to 5 minutes ...\r\n2012-07-14 16:30:32 5 of 5 :SUCCESS: DONE: Check the state of patch on cells.\r\n\r\n[root@exadb01 patch_11.2.3.1.1.120607]#<\/pre>\n
[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root imageinfo\r\nexacel01:\r\nexacel01:\r\nexacel01: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64\r\nexacel01: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607\r\nexacel01: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1\r\nexacel01:\r\nexacel01: Active image version: 11.2.3.1.1.120607\r\nexacel01: Active image activated: 2012-07-14 15:51:10 -0300\r\nexacel01: Active image status: success\r\nexacel01: Active system partition on device: \/dev\/md6\r\nexacel01: Active software partition on device: \/dev\/md8\r\nexacel01:\r\nexacel01: In partition rollback: Impossible\r\nexacel01:\r\nexacel01: Cell boot usb partition: \/dev\/sdm1\r\nexacel01: Cell boot usb version: 11.2.3.1.1.120607\r\nexacel01:\r\nexacel01: Inactive image version: 11.2.2.3.5.110815\r\nexacel01: Inactive image activated: 2011-09-24 04:02:31 -0300\r\nexacel01: Inactive image status: success\r\nexacel01: Inactive system partition on device: \/dev\/md5\r\nexacel01: Inactive software partition on device: \/dev\/md7\r\nexacel01:\r\nexacel01: Boot area has rollback archive for the version: 11.2.2.3.5.110815\r\nexacel01: Rollback to the inactive partitions: Possible\r\nexacel02:\r\nexacel02:\r\nexacel02: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64\r\nexacel02: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607\r\nexacel02: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1\r\nexacel02:\r\nexacel02: Active image version: 11.2.3.1.1.120607\r\nexacel02: Active image activated: 2012-07-14 16:29:39 -0300\r\nexacel02: Active image status: success\r\nexacel02: Active system partition on device: \/dev\/md5\r\nexacel02: Active software partition on device: \/dev\/md7\r\nexacel02:\r\nexacel02: In partition rollback: Impossible\r\nexacel02:\r\nexacel02: Cell boot usb partition: \/dev\/sdm1\r\nexacel02: Cell boot usb version: 11.2.3.1.1.120607\r\nexacel02:\r\nexacel02: Inactive image version: 11.2.1.3.1\r\nexacel02: Inactive image activated: 2012-03-21 15:28:37 -0300\r\nexacel02: Inactive image status: success\r\nexacel02: Inactive system partition on device: \/dev\/md6\r\nexacel02: Inactive software partition on device: \/dev\/md8\r\nexacel02:\r\nexacel02: Boot area has rollback archive for the version: 11.2.1.3.1\r\nexacel02: Rollback to the inactive partitions: Possible\r\nexacel03:\r\nexacel03:\r\nexacel03: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64\r\nexacel03: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607\r\nexacel03: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1\r\nexacel03:\r\nexacel03: Active image version: 11.2.3.1.1.120607\r\nexacel03: Active image activated: 2012-07-14 15:52:57 -0300\r\nexacel03: Active image status: success\r\nexacel03: Active system partition on device: \/dev\/md6\r\nexacel03: Active software partition on device: \/dev\/md8\r\nexacel03:\r\nexacel03: In partition rollback: Impossible\r\nexacel03:\r\nexacel03: Cell boot usb partition: \/dev\/sdm1\r\nexacel03: Cell boot usb version: 11.2.3.1.1.120607\r\nexacel03:\r\nexacel03: Inactive image version: 11.2.2.3.5.110815\r\nexacel03: Inactive image activated: 2011-09-24 04:02:32 -0300\r\nexacel03: Inactive image status: success\r\nexacel03: Inactive system partition on device: \/dev\/md5\r\nexacel03: Inactive software partition on device: \/dev\/md7\r\nexacel03:\r\nexacel03: Boot area has rollback archive for the version: 11.2.2.3.5.110815\r\nexacel03: Rollback to the inactive partitions: Possible\r\nexacel04:\r\nexacel04:\r\nexacel04: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64\r\nexacel04: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607\r\nexacel04: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1\r\nexacel04:\r\nexacel04: Active image version: 11.2.3.1.1.120607\r\nexacel04: Active image activated: 2012-07-14 15:50:46 -0300\r\nexacel04: Active image status: success\r\nexacel04: Active system partition on device: \/dev\/md6\r\nexacel04: Active software partition on device: \/dev\/md8\r\nexacel04:\r\nexacel04: In partition rollback: Impossible\r\nexacel04:\r\nexacel04: Cell boot usb partition: \/dev\/sdm1\r\nexacel04: Cell boot usb version: 11.2.3.1.1.120607\r\nexacel04:\r\nexacel04: Inactive image version: 11.2.2.3.5.110815\r\nexacel04: Inactive image activated: 2011-09-24 04:02:32 -0300\r\nexacel04: Inactive image status: success\r\nexacel04: Inactive system partition on device: \/dev\/md5\r\nexacel04: Inactive software partition on device: \/dev\/md7\r\nexacel04:\r\nexacel04: Boot area has rollback archive for the version: 11.2.2.3.5.110815\r\nexacel04: Rollback to the inactive partitions: Possible\r\nexacel05:\r\nexacel05:\r\nexacel05: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64\r\nexacel05: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607\r\nexacel05: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1\r\nexacel05:\r\nexacel05: Active image version: 11.2.3.1.1.120607\r\nexacel05: Active image activated: 2012-07-14 15:51:41 -0300\r\nexacel05: Active image status: success\r\nexacel05: Active system partition on device: \/dev\/md6\r\nexacel05: Active software partition on device: \/dev\/md8\r\nexacel05:\r\nexacel05: In partition rollback: Impossible\r\nexacel05:\r\nexacel05: Cell boot usb partition: \/dev\/sdm1\r\nexacel05: Cell boot usb version: 11.2.3.1.1.120607\r\nexacel05:\r\nexacel05: Inactive image version: 11.2.2.3.5.110815\r\nexacel05: Inactive image activated: 2011-09-24 04:02:31 -0300\r\nexacel05: Inactive image status: success\r\nexacel05: Inactive system partition on device: \/dev\/md5\r\nexacel05: Inactive software partition on device: \/dev\/md7\r\nexacel05:\r\nexacel05: Boot area has rollback archive for the version: 11.2.2.3.5.110815\r\nexacel05: Rollback to the inactive partitions: Possible\r\nexacel06:\r\nexacel06:\r\nexacel06: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64\r\nexacel06: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607\r\nexacel06: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1\r\nexacel06:\r\nexacel06: Active image version: 11.2.3.1.1.120607\r\nexacel06: Active image activated: 2012-07-14 15:51:21 -0300\r\nexacel06: Active image status: success\r\nexacel06: Active system partition on device: \/dev\/md6\r\nexacel06: Active software partition on device: \/dev\/md8\r\nexacel06:\r\nexacel06: In partition rollback: Impossible\r\nexacel06:\r\nexacel06: Cell boot usb partition: \/dev\/sdm1\r\nexacel06: Cell boot usb version: 11.2.3.1.1.120607\r\nexacel06:\r\nexacel06: Inactive image version: 11.2.2.3.5.110815\r\nexacel06: Inactive image activated: 2011-09-24 04:02:32 -0300\r\nexacel06: Inactive image status: success\r\nexacel06: Inactive system partition on device: \/dev\/md5\r\nexacel06: Inactive software partition on device: \/dev\/md7\r\nexacel06:\r\nexacel06: Boot area has rollback archive for the version: 11.2.2.3.5.110815\r\nexacel06: Rollback to the inactive partitions: Possible\r\nexacel07:\r\nexacel07:\r\nexacel07: Kernel version: 2.6.18-274.18.1.0.1.el5 #1 SMP Thu Feb 9 19:07:16 EST 2012 x86_64\r\nexacel07: Cell version: OSS_11.2.3.1.1_LINUX.X64_120607\r\nexacel07: Cell rpm version: cell-11.2.3.1.1_LINUX.X64_120607-1\r\nexacel07:\r\nexacel07: Active image version: 11.2.3.1.1.120607\r\nexacel07: Active image activated: 2012-07-14 15:50:22 -0300\r\nexacel07: Active image status: success\r\nexacel07: Active system partition on device: \/dev\/md6\r\nexacel07: Active software partition on device: \/dev\/md8\r\nexacel07:\r\nexacel07: In partition rollback: Impossible\r\nexacel07:\r\nexacel07: Cell boot usb partition: \/dev\/sdm1\r\nexacel07: Cell boot usb version: 11.2.3.1.1.120607\r\nexacel07:\r\nexacel07: Inactive image version: 11.2.2.3.5.110815\r\nexacel07: Inactive image activated: 2011-09-24 04:02:31 -0300\r\nexacel07: Inactive image status: success\r\nexacel07: Inactive system partition on device: \/dev\/md5\r\nexacel07: Inactive software partition on device: \/dev\/md7\r\nexacel07:\r\nexacel07: Boot area has rollback archive for the version: 11.2.2.3.5.110815\r\nexacel07: Rollback to the inactive partitions: Possible\r\n[root@exadb01 patch_11.2.3.1.1.120607]#\r\n[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root imageinfo|grep \"Active image version\"\r\nexacel01: Active image version: 11.2.3.1.1.120607\r\nexacel02: Active image version: 11.2.3.1.1.120607\r\nexacel03: Active image version: 11.2.3.1.1.120607\r\nexacel04: Active image version: 11.2.3.1.1.120607\r\nexacel05: Active image version: 11.2.3.1.1.120607\r\nexacel06: Active image version: 11.2.3.1.1.120607\r\nexacel07: Active image version: 11.2.3.1.1.120607\r\n[root@exadb01 patch_11.2.3.1.1.120607]#\r\n[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root imageinfo|grep \"Active image status\"\r\nexacel01: Active image status: success\r\nexacel02: Active image status: success\r\nexacel03: Active image status: success\r\nexacel04: Active image status: success\r\nexacel05: Active image status: success\r\nexacel06: Active image status: success\r\nexacel07: Active image status: success\r\n[root@exadb01 patch_11.2.3.1.1.120607]#<\/pre>\n
[root@exadb01 patch_11.2.3.1.1.120607]# dcli -g cell_group -l root grep -i fail \/var\/log\/cellos\/validations.log\r\nexacel01:\r\nexacel02:\r\nexacel03:\r\nexacel04:\r\nexacel05:\r\nexacel06:\r\nexacel07:\r\n[root@exadb01 patch_11.2.3.1.1.120607]#<\/pre>\n
[root@exadb01 patch_11.2.3.1.1.120607]# .\/patchmgr -cells cell_group -cleanup\r\nLinux 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\r\n\r\n2012-07-14 16:38:11 : DONE: Cleanup\r\n\r\n[root@exadb01 patch_11.2.3.1.1.120607]#<\/pre>\n