Arquitetura do Banco de Dados Oracle 11g no Windows

VISÃO GERAL EXECUTIVA

O Banco de Dados Oracle 11g no Windows apresenta uma solução de banco de dados otimizada para implantações que precisam de escalabilidade, confiabilidade e alto desempenho. Este documento descreve a arquitetura do banco de dados da Oracle para Windows e seu diferencial com relação aos congêneres executados em UNIX e Linux.

Usando um modelo de serviço nativo do Windows baseado em threads, o Banco de Dados Oracle 11g garante alto desempenho e escalabilidade. O banco de dados Oracle integra-se bem aos recursos avançados do sistema operacional Windows e ao hardware subjacente, como suporte a páginas grandes e NUMA. A Oracle oferece o melhor desempenho com o suporte para memória extensa, arquivos grandes e brutos e grid computing.

O banco de dados Oracle é certificado para os sistemas operacionais Windows de 32 e 64 bits. O banco de dados Oracle de 32 bits é suportado no Windows de 32 bits com hardware x86 padrão, incluindo o Windows Vista. No Windows de 64 bits, o Oracle de 64 bits funciona nos sistemas operacionais Windows x64 (AMD64/EM64T) e Windows Itanium. O hardware de 64 bits oferece mais escalabilidade e desempenho do que os sistemas de 32 bits.

INTRODUÇÃO

O banco de dados Oracle tornou-se uma das principais soluções para a plataforma Windows. Desde o início, o objetivo da Oracle sempre foi oferecer o banco de dados com o melhor desempenho e mais integrado ao Windows; para isso, a Oracle investiu desde cedo na mudança de sua tecnologia de banco de dados UNIX, líder de mercado, para a plataforma Windows. Em 1993, a Oracle foi a primeira empresa a lançar um banco de dados relacional para o Windows NT.

Inicialmente, os esforços de desenvolvimento da Oracle concentraram-se em aprimorar a performance e otimizar a arquitetura do banco de dados no Windows. O Oracle7 no Windows NT foi redesenhado para tirar proveito dos diversos recursos exclusivos da plataforma Windows, incluindo o suporte a thread nativo e a integração com algumas das ferramentas administrativas do Windows, como Monitor de desempenho e Visualizar eventos.

O banco de dados Oracle no Windows evoluiu de um nível básico de integração com o sistema operacional e passou a usar serviços mais avançados da plataforma Windows, incluindo os sistemas Itanium e AMD64/EM64T. Como sempre, a Oracle continua inovando e aproveitando as novas tecnologias do Windows. Este white paper aborda em detalhes a arquitetura do Banco de Dados Oracle 11g no Windows. Abrange também as inovações que aprimoram o banco de dados para Windows, mas não trata de recursos que se aplicam a todas as plataformas de hardware.

ARQUITETURA DO BANCO DE DADOS ORACLE NO WINDOWS

Quando executado no Windows, o Banco de Dados Oracle 11g contém os mesmos recursos e funcionalidades das várias plataformas Linux e UNIX para as quais a Oracle oferece suporte. No entanto, a interface entre o banco de dados e o sistema operacional foi bastante alterada para aproveitar os serviços exclusivos disponibilizados pelo Windows. Como resultado, o Banco de Dados Oracle 11g para Windows não é uma transferência direta da base de código do UNIX. Foi feito um trabalho de engenharia considerável para garantir que o banco de dados explore os recursos do Windows em sua plenitude e para assegurar que o banco de dados Oracle seja um sistema estável, confiável e de alto desempenho no qual desenvolver aplicativos.

Modelo de thread

Comparado ao banco de dados Oracle no UNIX, a alteração arquitetural mais significativa do Banco de Dados Oracle 11g no Windows é a conversão de servidor com base em processos em servidor com base em threads. No UNIX, o Oracle utiliza processos para implementar tarefas em segundo plano, como gerador do banco de dados (DBW0), gerador de log (LGWR), distribuidores (dispatchers), servidores compartilhados e afins. Além disso, cada conexão dedicada ao banco de dados faz com que outro processo do sistema operacional seja gerado em favor dessa sessão. No Windows, porém, todos esses processos são implementados como threads em um grande e único processo. Isso significa que, para cada instância do banco de dados Oracle, haverá apenas um processo em execução no Windows para o próprio servidor de banco de dados Oracle. (Observação: Existem outros processos Oracle no Windows para outros serviços do banco de dados, como o Enterprise Manager Database Console. Por dentro desse processo estão muitos threads em execução, sendo que cada um equivale a um processo na arquitetura UNIX. Dessa maneira, se houvesse 100 processos Oracle sendo executados no UNIX para uma instância específica, essa mesma carga de trabalho seria manipulada por 100 threads em um único processo no Windows.

Em termos operacionais, os aplicativos de cliente que se conectam ao banco de dados não são afetados por essa modificação na arquitetura do banco de dados. Todos os esforços foram empreendidos para garantir que o banco de dados funcione no Windows da mesma maneira que em outras plataformas, embora a arquitetura do processo interno tenha sido convertida para uma abordagem baseada em thread.

A mudança para uma arquitetura baseada em threads foi originalmente motivada por problemas de desempenho da primeira versão do Windows NT ao lidar com arquivos compartilhados entre processos. A simples conversão para uma arquitetura baseada em threads sem alterar qualquer outro código melhorou drasticamente o desempenho, já que assim se evitava esse gargalo específico do Windows NT. Não há dúvida de que a motivação original da mudança não existe mais; contudo, a arquitetura de thread para o Oracle continua, já que se mostrou muito estável e sustentável.

Há outros benefícios produzidos pela arquitetura de thread. Entre esses benefícios estão: trocas de contexto de sistema operacional mais rápidas entre os threads (em oposição aos processos); uma rotina de alocação da área global do sistema (SGA) muito mais simples que não requer o uso de memória compartilhada; disseminação mais rápida de novas conexões, uma vez que os threads são criados mais rapidamente do que os processos; menor utilização de memória, porque os threads compartilham mais estruturas de dados do que os processos; e, por fim, existência de uma impressão de que o modelo baseado em thread é um tanto mais “parecido com o Windows” do que um modelo baseado em processo.

Internamente, o código para implementação do modelo de thread é compacto e bastante isolado do corpo principal do código do Oracle. Menos de 20 módulos proporcionam toda a infra-estrutura necessária para implementação do modelo de thread. Além disso, foi acrescentada robustez à arquitetura através do uso de manipuladores de exceção e também de rotinas utilizadas para acompanhamento e desalocação dos recursos. Essas duas adições ajudam os aplicativos do banco de dados Oracle no Windows a satisfazer os requisitos das operações 24×7, sem inatividade decorrente de falhas de recursos ou programas com mau funcionamento.

Serviços

Além de se basear em thread, o Banco de Dados Oracle 11g não é um processo comum do Windows. É um serviço do Windows, que basicamente consiste em um processo de segundo plano registrado com o sistema operacional, ativado pelo Windows no momento da inicialização e executado em determinado contexto de segurança. A conversão do Oracle em um serviço era necessária para possibilitar que o banco de dados fosse ativado automaticamente na reinicialização do sistema, já que os serviços não requerem interação com o usuário para serem iniciados. Quando o serviço de banco de dados Oracle começa, não há nenhum dos threads Oracle típicos sendo executados no processo. Em vez disso, o processo basicamente espera por uma conexão inicial e uma solicitação de inicialização do SQL*Plus, que fará com que um thread de primeiro plano seja iniciado e então, por fim, cause a criação dos threads de segundo plano e da SGA. Quando o banco de dados é encerrado, todos os threads criados são concluídos, mas o processo em si continua a ser executado e aguarda a solicitação de conexão e o comando de inicialização seguintes. Além do serviço do banco de dados Oracle, foi incluído ainda suporte para a disseminação automática do SQL*Plus para iniciar e abrir o banco de dados para uso pelos clientes.

O Oracle Net Listener é um serviço que também precisa ser executado antes que os usuários possam se conectar ao banco de dados. Vale relembrar que tudo isso são detalhes da implementação que não afetam a maneira como os clientes conectam-se ou usam o banco de dados, embora seja muito importante para os administradores de bancos de dados do Windows.

Aprimoramentos de escalabilidade

Um dos principais objetivos do Banco de Dados Oracle 11g no Windows é explorar plenamente todas as tecnologias de sistema operacional e hardware que possam ajudar a aumentar a escalabilidade, a taxa de transferência e a capacidade do banco de dados.

Foram realizadas muitas atividades visando a comportar grandes números de usuários do banco de dados conectados no Windows. Desde o Oracle7 versão 7.2, há clientes em ambientes de produção com mais de 1.000 conexões simultâneas a uma única instância do banco de dados no Windows NT. Com o passar do tempo, esse número cresceu até atingir mais de 2.000 usuários conectados simultaneamente a uma mesma instância do banco de dados em um único nó em ambientes de produção. Ao usar a arquitetura de servidor compartilhado da Oracle, que limita o número de threads em execução no processo do banco de dados Oracle, chegamos a mais de 10.000 conexões simultâneas a uma única instância do banco de dados. Além disso, os recursos de multiplexação da rede e de pool de conexões também permitem que uma grande configuração tenha mais usuários conectados a uma única instância do banco de dados.

Nos últimos anos, os administradores de bancos de dados do Windows puderam aumentar ainda mais a quantidade de usuários empregando novo hardware de 64 bits, Itanium ou AMD64/EM64T, e o Oracle Real Application Clusters (RAC). Os aprimoramentos em 64 bits são discutidos adiante neste documento. O Oracle RAC permite que vários servidores acessem os mesmos arquivos do banco de dados, aumentando assim a capacidade de conexões de usuários, além da taxa de transferência.

Por ser possível acrescentar hardware comum na forma de nós adicionais de um cluster RAC, o RAC tornou-se uma solução comum de redimensionamento econômico e alta disponibilidade. No Windows, os clientes foram escalados para um cluster RAC com 23 nós sem problema algum.

4 GB RAM Tuning (4GT)

Quando o cluster e o Windows de 64 bits não são alternativas viáveis, é necessário maximizar os recursos disponíveis nos sistemas Windows de 32 bits. O Windows 2000 Server de 32 bits (edições Advanced e Datacenter) e o Windows Server 2003 de 32 bits (edições Enterprise e Datacenter) possuem um recurso chamado 4 GB RAM Tuning (4GT). Ele permite que os aplicativos do Windows que usam muita memória acessem diretamente até 3 GB de memória, em vez dos 2 GB permitidos como padrão. A vantagem óbvia para o banco de dados Oracle é que há 50% mais memória disponível para o banco de dados, que pode se utilizada para aumentar os tamanhos de SGA ou a quantidade de conexões. Todas as versões de servidor do banco de dados Oracle, desde a versão 7.3.4, ofereciam suporte a esse recurso sem precisar de alterações na instalação padrão da Oracle. A única mudança de configuração necessária visa a garantir que o sinalizador /3GB seja usado no arquivo Windows boot.ini.

Memória muito extensa (VLM, Very Large Memory)

O que normalmente se utiliza com aplicativos para o Windows de 32 bits que precisam de muita memória é um importante recurso de ajuste de memória, originalmente suportado pelo Oracle8i, chamado memória muito extensa (VLM, Very Large Memory).

A VLM, disponível a partir do Windows 2000, permite que o banco de dados Oracle no Windows ultrapasse o limite do espaço de endereço de 3 GB normalmente imposto pelo Windows de 32 bits. Especificamente, uma única instância do banco de dados agora pode acessar até 64 GB de buffers do banco de dados ao ser executada em uma máquina e em um sistema operacional que suporte essa quantidade de memória física.

Esse suporte no Banco de Dados Oracle 11g foi estritamente integrado ao código de cache do buffer do kernel do banco de dados, permitindo assim um uso muito eficiente de grandes quantidades de RAM disponíveis nos buffers do banco de dados. Com a configuração de um banco de dados com um grande número de buffers, mais dados são armazenados na memória. Isso reduz o volume de I/O do disco, uma ação consideravelmente mais lenta do que a recuperação de dados da memória. O uso desse recurso leva a um respectivo aumento na taxa de transferência e no desempenho do banco de dados.

Nos bastidores, o Banco de Dados Oracle 11g para Windows utiliza Address Windowing Extensions (AWE), incorporadas aos sistemas operacionais a partir do Windows 2000. As AWE são um conjunto de chamadas de API que permitem que os aplicativos acessem mais memória do que os tradicionais 3 GB de RAM normalmente disponíveis para aplicativos do Windows de 32 bits. A interface AWE tira proveito da arquitetura Intel Xeon e oferece uma rápida interface de mapeamento/desmapeamento para toda a memória de uma máquina. Sendo assim, ao acessar mais de 4 GB de memória, estritamente falando, os aplicativos não têm acesso direto à memória. Se o buffer requisitado do banco de dados estiver em uma área da memória superior a 4 GB, ele terá de ser mapeado dessa área para a memória inferior a 4 GB para poder ser acessado pelo banco de dados de 32 bits. Embora esse processo seja mais lento do que o acesso direto à memória, é consideravelmente mais rápido do que usar o disco.

As chamadas AWE permitem um grande aumento no uso do buffer do banco de dados, de até 64 GB do total de buffers. Esse suporte é puramente uma alteração na memória, sem alterações ou modificações feitas nos arquivos do banco de dados em si.

Páginas grandes

O suporte a página grande é um recurso que impulsiona o desempenho das instâncias do banco de dados que usam muita memória nas versões de 32 e 64 bits do Windows Server 2003. Os bancos de dados Oracle podem usar com mais eficiência os recursos de endereçamento de memória do processador com esse recurso. Especificamente, com o suporte para página grande habilitado, as CPUs do sistema poderão acessar com mais rapidez os buffers do banco de dados Oracle que estão na memória. O Oracle usa o suporte para página grande disponível no Windows. O tamanho de página é de 2 MB se a extensão de endereço físico (PAE, Physical Address Extension) estiver habilitada ou 4 MB se estiver desabilitada (no Windows de 32 bits); 2 MB (no Windows x64); ou 16 MB (no Windows Itanium). As páginas grandes são usadas na SGA. Todos os componentes da SGA, incluindo o cache do buffer, pool compartilhado, pool grande e outros, são alocados a partir dessas páginas grandes.

Esse recurso é especialmente útil quando o tamanho do cache do buffer do Oracle compreende muitos gigabytes. Configurações menores também terão um ganho usando páginas grandes, mas ele não será tão expressivo como no caso do banco de dados que acessa grandes quantidades de memória. Para habilitar esse novo recurso, a variável do registro ORA_LPENABLE deve ser configurada como 1 na chave Oracle do Registro do Windows.

Configurações de prioridade e afinidade

O banco de dados Oracle suporta a modificação das configurações de prioridade e afinidade do processo do banco de dados e dos threads individuais nesse processo ao ser executado no Windows.

Através da modificação do valor da configuração de Registro ORACLE_PRIORITY, um administrador de banco de dados pode atribuir diferentes prioridades do Windows aos threads de segundo plano individuais e também aos threads de primeiro plano como um todo. Da mesma forma, a prioridade de todo o processo do Oracle também pode ser modificada. Em determinadas circunstâncias, isso pode melhorar um pouco o desempenho. Por exemplo, se um aplicativo gerar muita atividade de arquivos de log, a prioridade do thread LGWR poderá ser aumentada para atender melhor à carga colocada. De igual maneira, se a replicação for usada com intensidade, esses threads que atualizam os dados de bancos remotos de forma bidirecional também podem ter sua prioridade aumentada.

De modo muito semelhante à configuração ORACLE_PRIORITY, a configuração de Registro ORACLE_AFFINITY permite que um administrador de banco de dados atribua todo o processo do Oracle ou threads individuais nesse processo a CPUs ou grupos de CPUs específicos do sistema. Relembrando: em alguns casos, isso pode ajudar a performance. Por exemplo, vincular o DBW0 a uma única CPU para que não migre de uma CPU para outra pode, em alguns casos, proporcionar uma pequena melhoria na performance. Além disso, se houver outros aplicativos em execução no sistema, a utilização da configuração ORACLE_AFFINITY pode ser uma forma de manter o Oracle confinado a um subconjunto das CPUs disponíveis a fim de proporcionar aos outros aplicativos tempo para que sejam executados.

Acesso não-uniforme à memória (NUMA, Non-Uniform Memory Access)

Com a inclusão do suporte a NUMA no Windows Server 2003, o Oracle agora pode explorar melhor o hardware NUMA, no qual um único servidor físico de grande porte é formado por vários “nós” computacionais. Como cada nó de uma máquina NUMA acessa partes diferentes da RAM física em velocidades distintas, é essencial que o banco de dados possa determinar a topologia de uma máquina NUMA e ajustar sua programação, as alocações de memória e as operações internas de acordo.

Ao ser executado em uma máquina NUMA, o banco de dados Oracle configura automaticamente o parâmetro ORACLE_AFFINITY com um valor padrão apropriado na inicialização para maximizar o uso dos recursos dessa máquina.

Além disso, as alocações de memória da SGA e PGA são feitas com reconhecimento do NUMA, para que essa memória seja acessada da maneira mais eficiente possível a partir de todos os diversos “nós” do servidor. Por fim, o número de threads geradores do banco de dados é configurado de modo que haja um por nó, como mais uma operação de melhoria do desempenho.

Aprimoramentos de I/O de arquivo

Outra área na qual se trabalhou muito no código do banco de dados Oracle é a do suporte a arquivos em cluster, arquivos grandes e arquivos brutos. O sistema de arquivos em cluster do Oracle é a parte integrante do Banco de Dados Oracle 11g que facilita a administração e a instalação dos clusters Oracle. Num esforço para garantir que todos os recursos do Windows sejam explorados em sua plenitude, o banco de dados suporta I/O de arquivo de 64 bits para permitir o uso de arquivo com tamanhos superiores a 4 GB. Além disso, são suportados arquivos brutos físicos e lógicos para arquivos de dados, log e controle, a fim de melhorar o desempenho usando o Oracle RAC e bancos de dados de uma única instância no Windows.

Sistema de arquivos em cluster

A capacidade de gerenciamento do Oracle RAC melhorou muito com o sistema de arquivos em cluster (CFS, Cluster File System) da Oracle. O Oracle CFS foi criado para ser usado especificamente com o RAC. Os executáveis do Oracle RAC são instalados no CFS ou em arquivos brutos. No caso do último, pelo menos uma instância do banco de dados é executada em cada nó do cluster. Em uma única instalação interna do Oracle com CFS, o banco de dados existirá no armazenamento compartilhado, geralmente uma array de armazenamento. O CFS permite que o software da Oracle seja acessado por todos os nós do cluster, mas controlado por nenhum deles. Todas as máquinas do CFS têm acesso igual a todos os dados e podem processar qualquer transação. Dessa forma, o RAC com CFS garante a redundância completa do software do banco de dados para clusters do Windows, enquanto simplifica a instalação e a administração.

I/O de arquivo de 64 bits

Internamente, todas as rotinas de I/O de arquivo do banco de dados Oracle suportam deslocamentos de arquivo de 64 bits, significando que não há limitações de tamanho de arquivo a 2 GB ou 4 GB quando se trata de arquivos de dados, log ou controle, como é o caso em algumas outras plataformas. Na realidade, as limitações existentes são limitações genéricas do Oracle em todas as portas. Essas limitações incluem 4 milhões de blocos de bancos de dados por arquivo, 16 KB de tamanho máximo de bloco e arquivos de 64 KB por banco de dados. Se esses valores forem multiplicados, o tamanho máximo de um arquivo de banco de dados no Windows será calculado como 64 GB, enquanto o tamanho total máximo de um banco de dados suportado (com blocos de banco de dados de 16 KB) será de 4 petabytes.

Suporte a arquivos brutos

Como o UNIX, o Windows suporta o conceito de arquivos brutos, que basicamente são partições de disco não-formatadas que podem ser usadas como um único arquivo grande. Os arquivos brutos têm a vantagem de não sobrecarregarem o sistema de arquivos, pois são partições sem formatação. Sendo assim, o uso de arquivos brutos como arquivos do banco de dados ou de log pode resultar em um pequeno ganho de desempenho. Entretanto, o aspecto negativo do uso de arquivos brutos é a capacidade de gerenciamento, porque os comandos padrão do Windows não suportam a manipulação ou o backup de arquivos brutos. Portanto, os arquivos brutos são usados geralmente apenas por instalações muito sofisticadas e pelo Oracle Real Application

Clusters, precisando de um desempenho otimizado. Para usar um arquivo bruto, tudo o que o Oracle precisa é um nome de arquivo que especifique qual letra de unidade ou partição usar para o arquivo. Por exemplo, o nome de arquivo \\.\PhysicalDrive3 diz ao banco de dados Oracle para usar a terceira (3ª) unidade física como um arquivo bruto físico como parte do banco de dados. Além disso, um arquivo como \\.\log_file_1 é um exemplo de arquivo bruto que foi atribuído com um alias para facilidade de compreensão. É possível atribuir aliases com o Oracle Object Link Manager (OLM). O OLM apresenta uma interface gráfica fácil de usar e mantém os links por todo o cluster e nas reinicializações. Durante a especificação de nomes de arquivos brutos para o banco de dados Oracle, todo cuidado é necessário para se escolher o número de partição ou a letra de unidade corretos, uma vez que o Oracle simplesmente sobrescreverá qualquer informação na unidade especificada quando adicionar o arquivo ao banco de dados, mesmo se já for uma unidade formatada como NTFS ou FAT.

Para o banco de dados Oracle, os arquivos brutos realmente não são diferentes de outros arquivos de bancos de dados Oracle. Os arquivos brutos são tratados da mesma maneira pelo Oracle e é possível executar seu backup e recuperação através do Recovery Manager como em qualquer outro arquivo.

Cliente direto do sistema de arquivos da rede – Novidade no 11g

O Banco de Dados Oracle 11g pode ser configurado para acessar servidores do sistema de arquivos da rede (NFS, Network File System) versão 3 diretamente, usando um cliente Oracle Direct Network File System interno.

Esse recurso é implementado como parte do kernel do banco de dados Oracle na biblioteca do Oracle Disk Manager. Sistemas baseados em NAS (Network Attached Storage) usam o NFS para acessar os dados. Nas versões anteriores do Oracle, o sistema operacional fornecia o driver do sistema de arquivos da rede do kernel para acessar dispositivos de armazenamento NAS. Essa instalação exigia parâmetros de configuração específicos para garantir o uso correto e eficiente com o Oracle. Se os parâmetros de configuração não fossem especificados corretamente, surgiam os seguintes problemas:

• Os clientes NFS eram muito inconsistentes entre as plataformas e variavam entre as versões do sistema operacional.

• Os parâmetros de configuração eram difíceis de ajustar. Há mais de 20 parâmetros NFS com diferenças sutis entre eles em todas as plataformas.

• A pilha de clientes NFS foi projetada para uso geral. Sendo assim, contém recursos, como o gerenciamento de atributos do arquivo, que não são necessários para o Oracle.

O Oracle Direct Network File System implementa o protocolo NFS Versão 3 no kernel do banco de dados, proporcionando gerenciamento mais fácil com características de desempenho melhores e mais previsíveis. Estas são as principais vantagens do uso dessa nova implementação:

• Permite o controle completo sobre os caminhos de entrada-saída para os servidores NFS, resultando em desempenho previsível, gerenciamento simplificado da configuração e diagnósticos melhores.

• Suas operações evitam gargalos na camada do sistema de arquivos de rede do kernel e limitações de recursos. Contudo, o kernel ainda é usado nos módulos de comunicação da rede.

Programa de gerenciamento de identidades página 11

Apresenta uma interface NFS comum para Oracle para o possível uso em todas as plataformas host e servidores NFS suportados.

• Possibilita um desempenho melhor por meio do balanceamento de carga entre várias conexões com os servidores NFS e canais de processamento de operações de entrada/saída assíncronas com simultaneidade aprimorada.

SISTEMAS OPERACIONAIS WINDOWS DE 64 BITS

O Windows e o hardware de 64 bits dão início a uma nova era em termos de desempenho e escalabilidade dos bancos de dados Oracle. Estão disponíveis duas plataformas Windows de 64 bits: a plataforma AMD64 e Intel EM64T e a plataforma Intel Itanium. A primeira usa o sistema operacional Windows x64. Ambas oferecem mais escalabilidade e desempenho do que suas congêneres de 32 bits.

A Oracle assumiu um compromisso sólido com essas plataformas de 64 bits. Foi a primeira empresa a disponibilizar ao público uma versão para desenvolvedor do banco de dados para Windows de 64 bits, tanto para Itanium como para AMD64/EM64T. A Oracle continuou mostrando o caminho na computação para Windows de 64 bits ao lançar uma versão para produção do banco de dados Oracle no mesmo dia em que o Windows Server 2003 de 64 bits para Itanium foi lançado. As equipes de desenvolvimento da Oracle trabalharam com a Microsoft, a Intel e a AMD para garantir o ótimo funcionamento do banco de dados em ambas as combinações de hardware e sistemas operacionais de 64 bits.

Assim como os bancos de dados de 64 bits da Oracle para plataformas UNIX, o banco de dados Oracle de 64 bits para Windows comporta mais conexões, aloca muito mais memória e oferece uma taxa de transferência superior ao do banco de dados de 32 bits.

O desempenho e a escalabilidade da Oracle aproveita muito bem os caches maiores e a memória disponível nos sistemas de 64 bits. Não existe mais a limitação a 4 GB de memória como nos sistemas de 32 bits, o que torna o Oracle de 64 bits perfeito para um intenso processamento de transações ou para aplicativos de business intelligence. Além disso, a Oracle aproveita as melhorias em paralelismo, programação e taxa de transferências disponíveis nas arquiteturas de 64 bits. Todos esses avanços de desempenho estão transparentemente disponíveis no banco de dados Oracle; sendo ssim, não são necessárias mudanças no código das implementações do banco de dados em uso.

Além do ganho de desempenho inerente obtido com a mudança para 64 bits, um dos principais aprimoramentos no desempenho empregados pela Oracle é a otimização por perfil (PGO, Profile-Guided Optimization). Com o compilador para Windows de 64 bits da Intel, a Oracle projetou seu banco de dados para funcionar bem com cargas de trabalho típicas dos clientes no Itanium e no AMD64/EM64T. Ao usar cargas de trabalho de clientes simuladas durante a compilação, um loop de feedback é fornecido ao compilador, que então pode analisar os caminhos do código mais e menos usados. A partir dessas informações, o compilador pode organizar os caminhos do código para ser mais eficiente quando executado em hardware de 64 bits. Somente com o uso do PGO sem nenhuma outra alteração, a Oracle conseguiu uma melhora de desempenho da ordem de 15% a 25%. Os aprimoramentos do PGO são transparentes para os aplicativos existentes, não exigindo alterações no código.

O caminho de migração do Oracle de 32 bits para 64 bits é bem direto. Não é preciso recriar bancos de dados nem fazer exportação e importação completas. Basta copiar os arquivos de dados atuais para o novo sistema, instalar a versão de 64 bits do Oracle, iniciar o banco de dados normalmente e executar alguns scripts SQL para atualizar o dicionário de dados.

Do ponto de vista arquitetural, a arquitetura atual baseada em thread é usada na migração para 64 bits. Ou seja, a criação do novo software Oracle de 64 bits basicamente implicou recompilar, revincular, testar novamente e relançar a nova versão.

Pouquíssimo código novo foi escrito durante a migração para 64 bits, pois as APIs do sistema operacional subjacente são basicamente as mesmas. Além disso, como o banco de dados Oracle já foi migrado para outros sistemas operacionais de 64 bits, a mudança para 64 bits é um processo direto que resultará em um produto estável e de qualidade, em um prazo bem curto.

Um dos benefícios de usar AMD64/EM64T é a capacidade de migrar facilmente aplicativos de 32 para 64 bits no mesmo sistema. Com esse hardware, os clientes podem executar o servidor de banco de dados e o cliente Oracle de 32 bits no Windows de 32 bits. Ou podem executar o sistema operacional no modo de 64 bits, enquanto o cliente Oracle continua no modo de 32 bits, embora outros aplicativos sejam convertidos para 64 bits. Ou podem migrar completamente para um conjunto Oracle de 64 bits no Windows x64. Essas opções facilitam o caminho de migração de 32 para 64 bits se houver diversos aplicativos executados na mesma máquina. Os clientes podem migrar seus aplicativos para 64 bits em um formato sistematizado.

CONCLUSÃO

O Banco de Dados Oracle 11g para Windows evoluiu de uma migração de seu servidor de banco de dados UNIX para um aplicativo nativo bem integrado que aproveita totalmente os serviços e recursos do sistema operacional Windows e do hardware subjacente. A Oracle continua a melhorar a performance, escalabilidade e capacidade de seu servidor de banco de dados no Windows, ao mesmo tempo produzindo uma plataforma estável e altamente funcional para o desenvolvimento de aplicativos. O compromisso da Oracle é oferecer um banco de dados com o melhor desempenho para as plataformas Windows de 32 e 64 bits.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s