Category Archives: Upgrade

ZDLRA, Patch/Update the Recovery Appliance

1 Reply

The process of patch ZDLRA is not complicated, but it is important to be aware of some details. The most important is from where you are until where you want to go. This is crucial because it will define what commands you will need to execute.

If you read the previous post about the process, you can notice that I was running the ZDLRA 12.2 version, and forwarded to 19.2 version. In that case, I needed to use the upgrade path since I was changing the major release and the racli commands had the “upgrade” parameter.

In this post I will show how to do a simple update (or patch apply) for ZDLRA, this means that I will remain inside the same major release for recovery appliance library. Some steps and checks are the same.

Whatever you need to do (patch or upgrade), the startup point it is the note 1927416.1 that cover the supported versions for ZDLRA. There it is possible to find all the supported versions for the recovery appliance library as well as the Exadata versions. Please, not upgrade the Exadata stack with a version that is not listed on this page.

Click here to read more…

Exadata and ZDLRA, Patch Exadata Stack

4 Replies

The process to patch Exadata stack and software changed in the last years and it became easier. Now, with patchmgr to be used for all (database servers, storage cells, and switches) the process is much easier to control the steps. Here I will show the steps that are involved in this process.

Independent if it is ZDLRA or Exadata, the process for Engineering System is the same. So, this post can be used as a guide for the Exadata patch apply as well. In 2018 I already made a similar process about how to patch/upgrade Exadata to 18c (you can access here) and even made a partial/incomplete post for 12c in 2015.

The process will be very similar and can be done in rolling and non-rolling mode. In the first, the services continue to run and you don’t need to shutdown databases, but will take more time because the patchmgr applies server by server. At the second, you need to shutdown the entire GI and the patch is applied in parallel and will be faster.

Click here to read more…

ZDLRA, Patch the Recovery Appliance

6 Replies

The proceed to patch/upgrade ZDLRA is not complicated, but as usual, some details need to be checked before starting the procedure. Since it is one engineering system based at Exadata, the procedure has one part that (maybe) needs to upgrade this stack too. But, is possible to upgrade just the recovery appliance library.

Whatever if need or no to upgrade the Exadata stack, the upgrade for recovery appliance library is the same. The commands and checks are the same. The procedure described in this post cover the upgrade of the recovery appliance library. For Exadata stack, it is in another post.

Where we are

Before even start the patch/upgrade it is important to know exactly which version you are running. To do this execute the command racli version at you database node:

[root@zeroinsg01 ~]# racli version
Recovery Appliance Version:
        exadata image: 19.2.3.0.0.190621
        rarpm version: ra_automation-12.2.1.1.2.201907-30111072.x86_64
        rdbms version: RDBMS_12.2.0.1.0_LINUX.X64_RELEASE
        transaction  : kadjei_julpsu_ip2
        zdlra version: ZDLRA_12.2.1.1.2.201907_LINUX.X64_RELEASE
[root@zeroinsg01 ~]#

With this, we can discover the ZDLRA version running (12.2.1.1.2.201907 in this case), and the Exadata image version (19.2.3.0.0.190621).

Click here to read more…

Solving MGMTDB errors during 18c GI RU apply

Leave a reply

Recently I executed the upgrade of Oracle GI to 19c version, from 18.6.0.0 to 19.5.0.0 version. But one step that was not showed there was that, because of requirements, the GI was upgraded from 18.2.0.0 to 18.6.0.0. This upgrade is a just Release Update (RU) apply and opatchauto command.

But during this upgrade, from 18.2 to 18.6, I faced (more than one time – 5 to be precise) errors during the update because of the MGMTDB errors. I got these errors:

  • ORA-12514, TNS: Listener does not currently know of service requested in connect descriptor
  • ORA-01017: invalid username/password; logon denied
  • MGTCA-1005 : Could not connect to the GIMR.
  • CRS-10407: (:CLSCRED1079:)Credential domain does not exist.

Here I will show how to solve these errors, how to identify if everything was fine and if you can continue. Be careful that it is an example, always open a support SR to identify the source of the error.

Click here to read more…

19c Grid Infrastructure Upgrade

5 Replies

Upgrade GRID infrastructure is one activity that usually is postponed because it involves a sensible area that, when not works, causes big downtime until be fixed. But, in the last versions, it is not a complicated task and if you follow the basic rules, it works without problems.

Here I will show a little example of how to upgrade the GI from 18.6.0 to 19.5. The steps below were executed at Exadata running version 19.2.7.0.0.191012 and GI 18.6.0.0, but can be done in every environment that supports Oracle GI.

Click here to read more…

ZDLRA, 19.2

1 Reply

Last week, at 27/August/2019, ZDLRA team released the new major version 19.2 (19.2.1.1.1) of Recovery Appliance Software. As always, some new features like supported databases, but some downsides too.

The main features for the software side:

  • Support for 19c databases.
  • Improved way to apply the patch (the rpm installation is not anymore manual).
  • Improved way to rollback the patch in some cases.

Other changes that deserve the hint:

  • Runs over 19.4 version of GRID and RDBMS.
  • Runs over Exadata System Software 19.2.3.0.0 (this means OEL 7) for DB and Storage.
  • Updated version for TFA, Exachk, and OEDA; all 19.x version.

Click here to read more…

Aplicando Patch no Exadata

3 Replies

O appliance Oracle Exadata é uma das tecnologias mais modernas para banco de dados Oracle, a união de Hardware e Software. Mas este software precisa ser atualizado de tempos em tempos você precisa aplicar o patch.

O time de Engineered Systems da Oracle disponibiliza os updates para serem aplicadas em toda a pilha: do Exadata Software aos binários do banco de dados. É tarefa do DMA acompanhar isso e deixar seu ambiente atualizado, muitas vezes (aqui no Brasil) estes updates são aplicados pelo time de ACS da Oracle, mas nada impede que você mesmo faça isso.

Este é o foco destes artigos, vou mostrar como proceder com um update completo do Oracle Exadata: Exadata Software, Infiniband, Linux, Update do Grid 11GR2 para 12C e Aplicação de BP nos binários do banco. Eu já descrevi sobre isso no meu blog a uns 3 anos atrás (aqui e aqui), mas muita coisa mudou desde aquela época.

Planejamento

De qualquer forma, antes de começar qualquer update (Oracle Exadata ou não) temos que planejar, verificar qual a versão que estamos e qual queremos aplicar.

Para o Oracle Exadata temos uma nota que contempla tudo isso e que é o início de qualquer update: Exadata Database Machine and Exadata Storage Server Supported Versions (Doc ID 888828.1). Nesta nota estão todas as informações importantes como documentação, as versões existentes, versões recomendadas e matriz de compatibilidade entre Exadata Software e binários do banco.

Então, o primeiro passo é o planejamento, ler e compreender esta nota, principalmente com as versões disponíveis e quais serão aplicadas. Outro ponto fundamental do planejamento é conhecer o seu ambiente, no meu caso a imagem que tenho aqui é a 11.2.3.3.0.

No tópico Exadata Storage Server 12c da nota identificamos que a última versão e que será aplicada aqui é a 12.1.2.1.2 (image version 12.1.2.1.2.150617.1) e composta pelos seguintes patches e docs:

  • Patch 20748218 – Storage server e InfiniBand
  • Patch 21151982 – Database server (para quem não utiliza OVM)
  • Readme – Note 2014306.1

Na mesma nota temos as versões do Grid Infrastructure e dos bancos de dados que são compatíveis com as imagens do Exadata. Como o meu planejamento inclui atualizar tudo para a última versão estes também serão atualizados.

Através da nota os seguintes updates serão realizados (e demonstrados aqui nestes artigos):

  • Update da imagem 11.2.3.3.0 para a 12.1.2.1.2 do Exadata (storage e bancos)
  • Upgrade da versão 11.2.0.4 BP 6 do Grid para a versão 12.1.0.2 BP 9
  • Update da versão 11.2.0.4 BP6 do banco de dados para a versão 11.2.0.4 BP 16

Pensando no appliance Oracle Exadata e na relação entre seus componentes o primeiro ponto a ser atualizado é a própria imagem do Exadata Storage Server (Linux, Exadata Software). Depois temos switchs Infiniband. Na sequência temos o update dos Database Servers e seus componentes (Grid e os binários do banco de dados).

Antes de iniciar o update precisamos montar o plano de atualização, qual a ordem de instalação dos patches. Isso só pode ser feito lendo todos os Readmes dos patches que vamos aplicar. Lendo o Readme do Patch 20748218 e Patch 21151982 descobrimos que existem dois métodos possíveis para atualizar o Database Server.

O primeiro é através da imagem ISO que acompanha o Patch 21151982 e o segundo é através da criação do repositório Exadata local. Este último método é o que utilizarei aqui, ele tem algumas vantagens que descreverei em detalhes depois mas é importante entender como funciona. Basicamente você cria um repositório local com os rpm’s que serão aplicados (os mesmo presentes na ISO). Infelizmente esta criação pode demorar um pouco e por isso será o primeiro procedimento a ser realizado.

Através da leitura de todas as notas do MOS envolvidas e de todos os Readmes dos patches aplicados o seguinte plano foi criado:

  1. Criação do repositório Exadata para Database Server
  2. Update do Storage Server e Switch Infiniband
  3. Update do Database Server
  4. Upgrade do GRID para 12C e Instalação dos binários 12C
  5. Update dos binários 11.2.0.4 para o BP16

Abaixo a descrição detalhas de cada uma destas etapas acima listadas.

A última atualização deste artigo foi em 03/08/2015.

Update VMware ESXi 5.x com vCLI

Leave a reply

Como no post anterior, o VMware ESXi 5 também pode ser atualizado através do vCLI. Nesta versão alguns comandos mudaram, mas o conceito permanece o mesmo.

Para o ESXi 5.0 em diante a forma básica de aplicação de updates continua na mesma linha, por não estar utilizando o vCenter não temos a centralização na aplicação dos updates. Além disso, todas as máquinas virtuais hospedadas no servidor ainda precisam ser paradas para aplicar o update.

Continue lendo…

Update VMware ESXi 4.1 com vCLI

1 Reply

Não é só de banco de dados que vive um DBA, as vezes temos que dar manutenção em diversos ambientes. Temos que nos preocupar com updates do sistema operacional, placa de rede, Storage e afins.

Recentemente tive que fazer uma atualização de um servidor com VMware onde era utilizado o ESXi 4.1. Infelizmente por ser ESXi algumas funcionalidades interessantes não estavam habilitadas, uma delas era o vCenter para gerência dos updates de forma centralizada.

Assim, tive que aplicar o update “na mão”. Como não é algo trivial resolvi compartilhar os passos para que possa auxiliar alguém que esteja na mesma situação. Aqui o update é para o ESXi 4.1 realizado de forma remota e atualizando para o último update. Os passos aqui descritos podem ser utilizados para qualquer update disponível no site da VMware, podendo ser um update completo ou um simples patch bundle.

Continue lendo…

Atualizando o Exadata – DBNODE

4 Replies

Diferentemente da atualização do storage node a do dbnode é mais complexa e não existe nada semelhante ao patchmgr para ajudar, é tudo feito através do passo a passo e manualmente. Prepare-se para um post extenso, com muita informação e com diversos logs de comandos executados. Tentei não poupar informações dos comandos executados para poder compartilhar o máximo, qualquer dúvida é só perguntar. Tudo o que está descrito aqui ocorreu a uns dois meses atrás durante a atualização do Exadata que executei.

Cabe resaltar que na versão 11.2.3.1.0 ocorreram grandes mudanças na forma como dbnode é atualizado. Na realidade esta versão é um divisor de águas no método de atualização. O primeiro local onde isso é citado é na nota 888828.1, que informa que o minimal pack foi descontinuado. O minimal pack era um arquivo que continha todos os pacotes dos aplicativos e bibliotecas do Linux e o kernel do dbnode a serem atualizado.

A partir da 11.2.3.1.0 a atualização passa a ser através da Unbreakable Linux Network (ULN), onde estão disponíveis todos os pacotes e repositórios da Oracle para Linux. Desta forma, você precisa criar um servidor que será um mirror de alguns dos canais disponíveis na ULN. Complicou não é? Calma que isso é só o começo.

Com base no readme do patch 13998727 (versão 11.2.3.1.1) somos informados que o método para criar este mirror está descrito no patch 13741363. Com base no readme deste patch somos apresentados aos requisitos e passos necessários para criar o mirror. A este método chamamos de One-Time Setup, servindo como preparação para a atualização do dbnode.

Infelizmente a documentação começa a ficar confusa neste ponto, se você observar no readme do patch para 11.2.3.1.1 você irá ver que os passos listados no passo 6 parecem incompletos. Na realidade eles estão, pois o passo 1 leva a ao One-Time que deve estar concluído e os outros remetem a passos de outra nota onde você deve trocar algumas informações para prosseguir. Bem complicado e suscetível a falhas, é importante saber ler nas entrelinhas.

Continue lendo…