Documentação do Oracle Cloud Infrastructure

Configurar Recursos do Oracle Database para o Exadata Cloud Infrastructure

Este tópico descreve como configurar o Oracle Multitenant, a criptografia de tablespaces e Huge Pages para uso com a instância do Exadata Cloud Infrastructure.

Usando o Oracle Multitenant em uma Instância do Exadata Cloud Infrastructure

Quando você cria uma Instância do Exadata Cloud Infrastructure que usa o Oracle Database 12c ou posterior, um ambiente do Oracle Multitenant é criado.

A arquitetura multitenant permite que um banco de dados Oracle funcione como um banco de dados contêiner (CDB) multitenant que inclui zero, um ou mais bancos de dados plugáveis (PDBs). Um PDB é um conjunto móvel de esquemas, objetos de esquema e objetos que não são de esquema que aparecem para um cliente Oracle Net Services como um não CDB. Todos os bancos de dados Oracle que usam versões anteriores ao Oracle Database 12c são não CDBs.

Para usar a TDE (Criptografia Transparente de Dados) da Oracle em um PDB (banco de dados plugável), você deve criar e ativar uma chave de criptografia principal para o PDB.

Em um ambiente multitenant, cada PDB tem sua própria chave de criptografia principal que é armazenada em um armazenamento de chaves usado por todos os contêineres.

Você deve exportar e importar a chave de criptografia principal para qualquer PDB criptografado conectado ao CDB da Instância do Exadata Cloud Infrastructure.

Se o PDB de origem estiver criptografado, exporte a chave de criptografia principal e importe-a.

Você pode exportar e importar todas as chaves de criptografia principais de TDE que pertencem ao PDB exportando e importando essas chaves de criptografia principais de TDE de um PDB. A exportação e a importação das chaves de criptografia principais de TDE suportam as operações de desplugamento e plugamento do PDB. Durante um desplugamento e plugamento de um PDB, todas as chaves de criptografia principais de TDE que pertencem a um PDB, assim como os metadados, são envolvidos.

Consulte "Exporting and Importing TDE Master Encryption Keys for a PDB" no Oracle Database Advanced Security Guide da Release 19, 18, 12.2 ou 12.1.

Consulte "ADMINISTER KEY MANAGEMENT" na Oracle Database SQL Language Reference da Release 19, 18, 12.2 ou 12.1.

Para determinar se você precisa criar e ativar uma chave de criptografia para o PDB

  1. Chame o SQL*Plus e faça log-in no banco de dados como o usuário SYS com privilégios SYSDBA.

  2. Defina o contêiner como PDB:

    SQL> ALTER SESSION SET CONTAINER = pdb;

  3. Consulte V$ENCRYPTION_WALLET da seguinte forma: 

    SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;

    Se a coluna STATUS contiver um valor OPEN_NO_MASTER_KEY, será necessário criar e ativar a chave de criptografia principal.

Para criar e ativar a chave de criptografia principal em um PDB

  1. Defina o contêiner como PDB:

    SQL> ALTER SESSION SET CONTAINER = pdb;

  2. Crie e ative uma chave de criptografia principal no PDB executando este comando:

    SQL> ADMINISTER KEY MANAGEMENT SET KEY USING TAG 'tag' FORCE KEYSTORE IDENTIFIED BY keystore-password WITH BACKUP USING 'backup_identifier';

    No comando anterior:

    • keystore-password corresponde à senha do armazenamento de chaves. Por padrão, a senha do armazenamento de chaves é definida como o valor da senha de administração que é especificada quando o banco de dados é criado.
    • A cláusula USING TAG 'tag' opcional pode ser usada para associar uma tag à nova chave de criptografia principal.
    • A cláusula WITH BACKUP e a cláusula USING 'backup_identifier' opcional podem ser usadas para criar um backup do armazenamento de chaves antes da criação da nova chave de criptografia principal.

    Consulte também ADMINISTER KEY MANAGEMENT na Oracle Database SQL Language Reference da Release 19, 18 ou 12.2.

    Observação

    Para ativar operações de gerenciamento de chaves enquanto o armazenamento de chaves estiver em uso, o Oracle Database 12c Release 2 e posteriores, inclui a opção FORCE KEYSTORE para o comando ADMINISTER KEY MANAGEMENT. Esta opção também está disponível para o Oracle Database 12c Release 1 com o patch do bundle de outubro de 2017 ou posterior.

    Se o banco de dados Oracle Database 12c Release 1 não tiver o patch do bundle de outubro de 2017, ou posterior, instalado, você poderá executar as seguintes etapas alternativas:

    1. Feche a área de armazenamento de chaves.
    2. Abra o armazenamento de chaves baseado em senha.
    3. Crie e ative uma chave de criptografia principal no PDB usando ADMINISTER KEY MANAGEMENT sem a opção FORCE KEYSTORE.
    4. Atualize o armazenamento de chaves de log-in automático usando o comando ADMINISTER KEY MANAGEMENT com a opção CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE.

  3. Consulte mais uma vez V$ENCRYPTION_WALLET para verificar se a coluna STATUS está definida como OPEN: 

    SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;

  4. Consulte V$INSTANCE e anote o valor na coluna HOST_NAME, que identifica o servidor de banco de dados que contém os arquivos de armazenamento de chaves atualizados recentemente: 

    SQL> SELECT host_name FROM v$instance;

  5. Copie os arquivos de armazenamento de chaves atualizados para todos os outros servidores de banco de dados.

    Para distribuir o armazenamento de chaves atualizado, você deve executar as seguintes ações em cada servidor de banco de dados que não contenha os arquivos de armazenamento de chaves atualizados:

    1. Conecte-se ao contêiner raiz e consulte V$ENCRYPTION_WALLET. Anote o local do armazenamento de chaves contido na coluna WRL_PARAMETER: 

      SQL> SELECT wrl_parameter, status FROM v$encryption_wallet;

    2. Copie os arquivos de armazenamento de chaves atualizados.

      Você deve copiar todos os arquivos de armazenamento de chaves atualizados de um servidor de banco de dados que já esteja atualizado. Use o local do armazenamento de chaves observado na coluna WRL_PARAMETER de V$ENCRYPTION_WALLET.

    Abra o armazenamento de chaves atualizado:
    SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE open FORCE KEYSTORE IDENTIFIED BY keystore-password CONTAINER=all;
    Observação

    Para ativar operações de gerenciamento de chaves enquanto o armazenamento de chaves estiver em uso, o Oracle Database 12c Release 2 e posteriores, inclui a opção FORCE KEYSTORE para o comando ADMINISTER KEY MANAGEMENT. Esta opção também está disponível para o Oracle Database 12c Release 1 com o patch do bundle de outubro de 2017 ou posterior.

    Se o banco de dados Oracle Database 12c Release 1 não tiver o patch do bundle de outubro de 2017, ou posterior, instalado, você poderá executar as seguintes etapas alternativas:

    1. Feche o armazenamento de chaves antes de copiar os arquivos de armazenamento de chaves atualizados.
    2. Copie os arquivos de armazenamento de chaves atualizados.
    3. Abra o armazenamento de chaves atualizado usando o comando ADMINISTER KEY MANAGEMENT sem a opção FORCE KEYSTORE.

  6. Consulte GV$ENCRYPTION_WALLET para verificar se a coluna STATUS está definida como OPEN em todas as instâncias do banco de dados: 

    SQL> SELECT wrl_parameter, status, wallet_type FROM gv$encryption_wallet;

Para exportar e importar uma chave de criptografia principal

  1. Exporte a chave de criptografia principal.
    1. Chame o SQL*Plus e faça log-in no PDB.

    2. Execute o seguinte comando:

      SQL> ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "secret" TO 'filename' IDENTIFIED BY keystore-password;
  2. Importe a chave de criptografia principal.
    1. Chame o SQL*Plus e faça log-in no PDB.

    2. Execute o seguinte comando:

      SQL> ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET "secret" FROM 'filename' IDENTIFIED BY keystore-password;

Gerenciando Criptografia de Tablespace

Por padrão, todos os novos tablespaces criados em um banco de dados Exadata são criptografados.

No entanto, os tablespaces que são criados inicialmente quando o banco de dados é criado podem não ser criptografados por padrão.

  • Para bancos de dados que usam o Oracle Database 12c Release 2 ou posterior, apenas os tablespaces USERS criados inicialmente quando o banco de dados foi criado são criptografados. Não há outros tablespaces criptografados, incluindo os não USERS em:
    • O contêiner raiz (CDB$ROOT).
    • O banco de dados plugável pré-implantado (PDB$SEED).
    • O primeiro PDB, que é criado quando o banco de dados é criado.
  • Para bancos de dados que usam o Oracle Database 12c Release 1 ou Oracle Database 11g, nenhum dos tablespaces criado inicialmente quando o banco de dados foi criado é criptografado.

Para obter mais informações sobre a implementação da criptografia de tablespace no Exadata, além de como ela afeta vários cenários de implantação, consulte Oracle Database Tablespace Encryption Behavior in Oracle Cloud.

Criando Tablespaces Criptografados

Por padrão, os tablespaces criados pelo usuário são criptografados.

Por padrão, todos os novos tablespaces criados usando o comando SQL CREATE TABLESPACE são criptografados com o algoritmo de criptografia AES128. Não é necessário incluir a cláusula USING 'encrypt_algorithm' para usar a criptografia padrão.

Você pode especificar outro algoritmo suportado incluindo a cláusula USING 'encrypt_algorithm' no comando CREATE TABLESPACE. Os algoritmos suportados são AES256, AES192, AES128 e 3DES168.

Gerenciando Criptografia de Tablespace

Você pode gerenciar o armazenamento de chaves de software (conhecido como wallet da Oracle no Oracle Database 11g), a chave de criptografia principal e controlar se a criptografia está ativada por padrão.

Gerenciando a Chave de Criptografia Principal

A criptografia de tablespace usa uma arquitetura de duas camadas baseada em chaves para criptografar (e descriptografar) tablespaces de forma transparente. A chave de criptografia principal é armazenada em um módulo de segurança externo (armazenamento de chaves do software). Essa chave de criptografia principal é usada para criptografar a chave de criptografia do tablespace, que por sua vez é usada para criptografar e descriptografar dados no tablespace.

Quando um banco de dados é criado em uma instância do Exadata Cloud Service, um armazenamento de chaves de software local é criado. O armazenamento de chaves é local nos nós de computação e é protegido pela senha de administração especificada durante o processo de criação do banco de dados. O armazenamento de chaves do software de log-in automático é aberto automaticamente quando o banco de dados é iniciado.

Você pode alterar (alternar) a chave de criptografia principal usando a instrução ADMINISTER KEY MANAGEMENT SQL. Por exemplo: 

SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY USING TAG 'tag'
IDENTIFIED BY password WITH BACKUP USING 'backup';
keystore altered.

Consulte "Managing the TDE Master Encryption Key" no Oracle Database Advanced Security Guide da Release 19, 18, 12.2 ou 12.1 ou "Setting and Resetting the Master Encryption Key" no Oracle Database Advanced Security Administrator's Guide da Release 11.2.

Controlando a Criptografia de Tablespace Padrão

O parâmetro de inicialização ENCRYPT_NEW_TABLESPACES controla a criptografia padrão de novos tablespaces. Em bancos de dados Exadata, esse parâmetro é definido como CLOUD_ONLY por padrão.

Os valores desse parâmetro são encontrados a seguir.

Valor Descrição
ALWAYS Durante a criação, os tablespaces são criptografados de forma transparente com o algoritmo AES128, a menos que um algoritmo distinto seja especificado na cláusula ENCRYPTION.
CLOUD_ONLY Os tablespaces criados em um banco de dados Exadata são criptografados de forma transparente com o algoritmo AES128, a menos que um algoritmo distinto seja especificado na cláusula ENCRYPTION. Para bancos de dados que não estão na nuvem, os tablespaces só serão criptografados se a cláusula ENCRYPTION for especificada. ENCRYPTION é o valor padrão.
DDL Durante a criação, os tablespaces não são criptografados de forma transparente por padrão e só são criptografados se a cláusula ENCRYPTION for especificada.
Observação

Com o Oracle Database 12c Release 2 (12.2) ou posterior, não é mais possível criar um tablespace não criptografado em um banco de dados Exadata. Uma mensagem de erro será retornada se você definir ENCRYPT_NEW_TABLESPACES como DDL e emitir um comando CREATE TABLESPACE sem especificar uma cláusula ENCRYPTION.

Gerenciando Huge Pages

O recurso Huge Pages fornece benefícios de desempenho consideráveis para o Oracle Database em sistemas com grandes quantidades de memória. O Oracle Database em uma instância do Exadata Cloud Infrastructure fornece definições de configuração que usam Huge Pages por padrão; no entanto, você pode fazer ajustes manuais para otimizar a configuração de Huge Pages.

Huge Pages é um recurso integrado ao kernel do Linux 2.6. A ativação do recurso Huge Pages possibilita ao sistema operacional oferecer suporte a páginas de memória grande. O uso do Huge Pages pode melhorar o desempenho do sistema reduzindo a quantidade de CPU e recursos de memória do sistema necessários para gerenciar tabelas de páginas do Linux, que armazenam o mapeamento entre endereços de memória virtual e física. Para Oracle Databases, o uso do Huge Pages pode reduzir drasticamente o número de entradas de tabelas de páginas associadas à SGA (System Global Area).

Em instâncias do Exadata Cloud Infrastructure, uma página padrão tem 4 KB e uma Huge Page tem 2 MB por padrão. Portanto, um Oracle Database em um sistema de banco de dados Exadata com uma SGA de 50 GB requer 13.107.200 páginas padrão para armazenar a SGA, em comparação com apenas 25.600 do Huge Pages. O resultado são tabelas de páginas muito menores, que exigem menos memória para armazenar e menos recursos da CPU para acessar e gerenciar.

Ajustando a Configuração de Huge Pages

A configuração de Huge Pages para o Oracle Database é um processo de duas etapas:

  • No nível do sistema operacional, a quantidade total de memória alocada para Huge Pages é controlada pela entrada vm.nr_hugepages no arquivo /etc/sysctl.conf. Essa definição é feita em cada nó de computação no ambiente e é recomendável que a definição seja consistente em todos os nós de computação. Para alterar a alocação do Huge Page, você pode executar o seguinte comando em cada nó de computação como usuário raiz: 

    # sysctl -w vm.nr_hugepages=value

    em que value corresponde ao número de Huge Pages que você deseja alocar.

    Nas instâncias do Exadata Cloud Infrastructure, cada Huge Page tem 2 MB por padrão. Portanto, para alocar 50 GB de memória para Huge Page, você pode executar o seguinte comando: 

    # sysctl -w vm.nr_hugepages=25600
  • No nível do Oracle Database, o uso de Huge Pages é controlado pela definição do parâmetro de instância USE_LARGE_PAGES. Essa definição se aplica a cada instância de banco de dados em um banco de dados clusterizado. A Oracle recomenda uma definição consistente em todas as instâncias de banco de dados associadas a um banco de dados. As seguintes opções estão disponíveis:
    • TRUE – especifica que a instância do banco de dados pode usar Huge Pages se elas estiverem disponíveis. Para todas as versões do Oracle Database após a versão 11.2.0.3, a Oracle alocará o máximo da SGA possível, usando Huge Pages. Quando a alocação de Huge Pages é esgotada, as páginas de memória padrão são usadas.
    • FALSE – especifica que a instância do banco de dados não usa Huge Pages. Essa definição geralmente não é recomendada se houver Huge Pages disponíveis.
    • ONLY – especifica que a instância do banco de dados deve usar Huge Pages. Com essa definição, a instância do banco de dados não será iniciada se toda a SGA não for acomodada em Huge Pages.

Se você fizer ajustes no nível do sistema operacional ou do Oracle Database, verifique se a configuração geral funciona.

Para obter mais informações, consulte o Oracle Database Administrator's Reference for Linux and UNIX-Based Operating Systems da Release 19, 18, 12.1 ou 11.2 para obter uma visão geral de Huge Pages e mais informações sobre a configuração de Huge Pages. Além disso, consulte USE_LARGE_PAGES na Oracle Database Reference da Release 12.2, 12.1 ou 11.2.