Artigos Banco de Dados Upgrade do Oracle 11g para 12c - Parte 1

Artigo no estilo: Curso

Demais posts desta série:
Upgrade do Oracle 11g para 12c - Partes 3 e 4
Por que eu devo ler este artigo:Não há grande consenso entre os gerentes e os profissionais de infraestrutura de banco de dados a respeito da real necessidade em executar a migração ou upgrade do Banco de Dados da empresa. No entanto é nosso dever mostrar esta necessidade e, acima de tudo, executar o processo após autorização para tal.

Dependendo da versão atual do banco não será possível efetuar o upgrade diretamente para a última versão do produto. No entanto, mesmo que a versão atual permita o upgrade direto, há ainda a necessidade de definir qual a melhor metodologia a ser adotada para o processo. Apresentaremos aqui também quais os métodos disponíveis para execução da tarefa.

A discussão desse tema é útil em cenários onde a versão do bando de dados Oracle já está fora da matriz de suporte do fornecedor ou quando há uma nova funcionalidade que pode agregar muito ao desempenho e operação da aplicação em relação ao bando de dados.

Várias pessoas questionam a real necessidade em executar a migração ou upgrade do banco de dados da empresa ou mesmo de seu cliente. Muitas vezes é difícil convencer o cliente ou o gerente desta necessidade uma vez que eles apenas “olham” o banco de dados como um back-end para a aplicação principal.

Um back-end database é um banco de dados que é acessado por usuários indiretamente através de um aplicativo externo ao invés de programação armazenada dentro do próprio banco ou através de manipulação dos dados (por exemplo, comandos SQL).

Um back-end database armazena dados, mas não inclui elementos de aplicação do usuário final, tais como consultas armazenadas, formulários, macros ou relatórios.

O termo back-end database é mais utilizado entre os desenvolvedores que usam pequenos sistemas de programação de banco de dados que podem conter a programação de aplicações do usuário final no banco de dados como um único módulo. O mais comum deles é o Microsoft Access.

O desenvolvedor deve decidir se deseja incluir a programação de aplicações com os dados em um único banco ou separá-los em dois módulos, de acordo com o modelo cliente-servidor.

Para aplicações de banco de dados simples, é comum que toda a programação seja armazenada juntamente com os dados. Isto resulta em um único módulo que acaba sendo mais fácil de desenvolver.

Já no caso de aplicações mais complexas, é comum dividir os dados e os módulos de programação em um front-end e um back-end onde o front-end tem toda a programação da aplicação, incluindo interface com o usuário. Isto tem vantagens em termos de escalabilidade, desempenho e simultaneidade, mas exige maior esforço por parte do desenvolvedor. No longo prazo, pode ser mais fácil de manter e as novas versões do front-end podem ser implantadas de forma independente do back-end. Os front-end e back-end nem sempre precisam ser do mesmo tipo. Por exemplo, é possível usar um front-end do Microsoft Access com banco de dados Oracle como back-end.

Se alguém está olhando apenas através da ótica da aplicação, uma atualização de banco de dados pode ser algo totalmente inútil, pois simplesmente custa tempo, esforço e dinheiro. No entanto, sabemos que as coisas não são bem assim e atualizações são realmente necessárias.

Os fatos a seguir podem contribuir no convencimento do cliente:

1. Período de suporte Oracle para a versão vai acabar em breve ou já acabou: ainda há muitos clientes utilizando a versão 10.2, mesmo após o primeiro ano de suporte estendido gratuito ter finalizado (já a bastante tempo) - ou seja, sem correções de bugs, a menos que se desembolsse 20% a mais no contrato de suporte para obter apoio avançado para problemas críticos por mais um ano. Já estamos na versão 12.1 e, acreditem, ainda há versões 9i em produção;

2. Os fornecedores de aplicações estão pressionando para que o uprgade seja feito: As versões mais recentes do Oracle E-Business Suite (EBS), Siebel, Peoplesoft, JD Edwards e mesmo do SAP exigirão as versões mais atuais do Oracle database, portanto o upgrade é inevitável;

3. Correções de segurança CPU e PSU (ver BOX 1): É comum lermos notícias e relatos referentes a sistema invadidos ou “hackeados”. É essencial ter as correções de segurança mais recentes. E estas correções estarão disponíveis somente durante o período de suporte premier, a menos que seja paga uma taxa extra para suporte estendido;

BOX 1. CPU e PSU: correção de bugs.

Em 14 de julho de 2009, a Oracle introduziu um novo método para aplicação de patches, chamado de Patch Set Update, ou PSU. De acordo com as notas 854428.1 e 850471.1 do portal MOS (My Oracle Support), o Oracle PSU é uma nova estratégia de correção em que o DBA pode escolher aplicar apenas as correções “recomendadas” e “proativas” ao invés de todas as correções em um Critical Patch Update (CPU) que é disponibilizado trimestralmente.

Um PSU contém correções de bugs recomendas e patches cumulativos “pró-ativos”. Esta é uma mudança interessante que torna mais simples para o DBA escolher apenas aplicar patches “prioritários”.

A cada trimestre, o Oracle Critical Patch Update (CPU) agora irá conter tanto o PSU quanto o CPU, de modo que o DBA pode optar por aplicar apenas o CPU ou aplicar todos os patches no pacote PSU (que inclui correções adicionais).

Além disso, o PSU permite aplicar o patch sem tempo de inatividade do banco de dados, pois permite que um bancos RAC tenha cada nó corrigido de forma independente, sem tempo de inatividade.

4. Potenciais economias - parte I: qual o principal fator de custo nos data centers modernos? Discos rápidos necessitando de toneladas de energia, especialmente para o resfriamento. As versões mais recentes (a partir da versão 11.2) oferecem compressão avançada (advanced compression) e se o DBA puder mostrar para o cliente que poderá economizar metade do espaço em disco é fácil perceber que o retorno do investimento de um upgrade aparece rapidamente, considerarando os custos de energia e os custos para novos armazenamentos;

5. Potenciais economias - parte II: Active Data Guard. É possível utilizar um banco de dados em standby no modo “somente leitura” para a geração de relatórios. Esta técnica diminui a sobrecarga de leitura no banco de dados principal, como a Apple faz com a plataforma iTunes e a amazon.com procede de forma semelhante. Será evitada a necessidade de aquisição de novo hardware por um longo tempo, os usuários finais terão uma experiência melhor em função da diminuição e distribuição do tráfego. No entanto, esta técnica só fará sentido se a empresa já possui um banco de dados em Standby;

6. Acesso mais rápido a dados tipo LOB – utilização de Secure Files (ver BOX 2): Não há custo extra pois está disponível tanto na versão Standard Edition quanto na Enterprise Edition, e permitirá que os usuários finais obtenham um acesso muito mais rápido aos dados do tipo CLOB/BLOB.

BOX 2. Secure Files.

A tecnologia Secure Files foi introduzida pela primeira vez no Oracle Database 11g, e permite uma grande mudança de paradigma para o armazenamento e gerenciamento de arquivos. Secure Files oferece a melhor solução para armazenar o conteúdo do arquivo, como imagens, áudio, vídeo, PDFs, planilhas, etc. Tradicionalmente, dados relacionais são armazenados em um banco de dados enquanto os dados não-estruturados são armazenados como arquivos no sistemas de arquivos. Secure Files foi especificamente projetado para oferecer alto desempenho para dados de arquivos semelhantes ao de sistemas de arquivos tradicionais, mantendo as vantagens do Oracle Database. Secure Files oferece a arquitetura “melhor dos dois mundos”, tanto do Banco de Dados quanto do sistema de arquivos para armazenar dados não estruturados. Com Secure Files a Oracle tem aperfeiçoado o uso do Banco de Dados para armazenamento de todos os dados de qualquer empresa.

LOBs, ou Large Objects (Objetos Grandes) podem ser do tipo BLOB – Binary Large Object (Objeto Grande Binário) – ou CLOB – Character Large Object (Objeto Grande de Caractere).

Um CLOB é uma coleção de dados de caracteres em um sistema de gerenciamento de banco de dados, normalmente armazenado em um local separado que é referenciado na própria tabela. Oracle e IBM DB2 fornecem uma construção explicitamente nomeada CLOB, e a maioria dos sistemas de banco de dados suportam alguma forma deste conceito, muitas vezes rotulado como TEXT, MEMO ou LONG.

CLOBs geralmente possuem limites de tamanho muito elevados, da ordem de 2 GB ou mais. A elevada capacidade é geralmente limitante para os métodos de acesso. Em particular, alguns sistemas de banco de dados SQL limitam determinadas cláusulas, tais como LIKE ou SUBSTRING de serem usadas em CLOBs.

Métodos alternativos de acesso aos dados são muitas vezes fornecidos, incluindo os meios de extração ou inserção de “pedaços” de dados a partir do CLOB.

Sistemas de banco de dados variam em seus padrões de armazenamento para CLOBs. Alguns sistemas sempre armazenam CLOBs como uma referência a dados “fora-de-tabela”, ao passo que outros armazenam pequenos CLOBs em tabelas, alterando os seus padrões de armazenamento quando o tamanho dos dados aumenta para além de um limite. Outros sistemas são configuráveis no seu comportamento.

CLOBs se distinguem dos BLOBs por ter uma codificação de caracteres especificada. Um BLOB é uma coleção de dados binários armazenados como uma única entidade em um sistema de gerenciamento de banco de dados. BLOBs são normalmente imagens, áudio ou outros objetos multimídia, embora muitas vezes um código executável binário é armazenado como um BLOB.

Agora que temos subsídios suficientes para fazer com que o cliente entenda e apoie a migração do banco de dados para a versão mais recente, é hora de colocar a “mão na massa” e realizar esta migração.

Upgrade versus Migração

Embora os termos Upgrade e Migração sejam usados frequentemente como sinônimos em outros contextos, há uma diferença entre upgrade do banco de dados e migração de banco de dados. Entender essa diferença é o primeiro passo na escolha do melhor método de upgrade ou migração para o projeto.

O upgrade de um banco de dados Oracle envolve modificar o dicionário de dados para ser compatível com a versão mais recente do software. Os tipos de modificações que podem ser parte de um upgrade de banco de dados incluem:

· Adicionar, excluir ou modificar colunas em tabelas ou views do sistema;

· A criação de novos packages (pacotes) ou stored procedures (procedimentos armazenados) do sistema;

· Modificar packages ou stored procedures existentes do sistema;

· Criar, modificar ou excluir usuários de banco de dados, roles e privilégios;

· Modificar dados que são usadas por componentes do banco.

Todas essas ações afetam o dicionário de dados. Elas não afetam os dados armazenados nos schemas ou tabelas da aplicação. Portanto, o volume de dados armazenados no banco tem pouca ou nenhuma influência sobre o upgrade do banco em si.

O termo “migração” aplica-se a vários tipos diferentes de alterações que podem ser aplicados a um banco. Além da versão do banco, uma migração pode incluir uma alteração em qualquer uma ou todas as seguintes características:

· Servidor de banco de dados;

· Arquitetura de armazenamento;

· Conjunto de caracteres (character set);

· Sistema operacional;

...
Quer ler esse conteúdo completo? Tenha acesso completo