Configurar o Autonomous AI Database com Arquitetura de Referência
Este caso de uso demonstra como configurar seus recursos do Autonomous AI Database na Infraestrutura Dedicada do Exadata para aproveitar melhor seus recursos. Esta é uma configuração abrangente e recomendada que aproveita a arquitetura de referência do Autonomous AI Database on Dedicated Exadata Infrastructure.
O Oracle Autonomous AI Database on Dedicated Exadata Infrastructure é um ambiente de banco de dados altamente automatizado e totalmente gerenciado executado na Oracle Cloud Infrastructure (OCI) com recursos de hardware e software comprometidos. Esses recursos isolados permitem que as organizações atendam a requisitos rigorosos de segurança, disponibilidade e desempenho, reduzindo o custo e a complexidade.
Dica: Se você estiver procurando orientação para configurar rapidamente um ambiente POC do Autonomous AI Database, consulte Configurar o Autonomous AI Database para Prova de Conceito (POC).
Conhecimento de Pré-requisito
Para entender e apreciar totalmente esse caso de uso, você deve ter uma compreensão básica do Autonomous AI Database on Dedicated Exadata Infrastructure, incluindo suas opções de implementação, principais componentes de infraestrutura, funções de usuário e principais recursos. Para obter informações mais detalhadas, consulte Sobre o Autonomous AI Database na Infraestrutura Dedicada do Exadata.
Caso de Uso
A Acme Company optou por usar o Autonomous AI Database na Infraestrutura Dedicada do Exadata para suas aplicações internas de projetos. O departamento de TI da Acme assumirá a atribuição de administrador de frota, responsável por criar e gerenciar recursos do Exadata Infrastructure (EI) e do Cluster de VMs do Autonomous Exadata (AVMC) para a empresa. Dentro de cada equipe de projeto ou linha de negócios, os usuários designados assumirão a atribuição de DBA da aplicação, encarregados de criar o Autonomous Container Database (ACD) e Autonomous AI Databases para seus usuários de banco de dados, incluindo desenvolvedores de aplicativos, testadores e implantadores.
Observação: Este exemplo ilustra o DBA da aplicação que está criando e gerenciando os recursos ACD. No entanto, sua organização pode preferir que o administrador da frota realize essa tarefa por conta própria.
A Acme I.T. alocará recursos para as diversas equipes, garantindo o fornecimento de AVMCs que atendam aos SLAs exigidos. Além disso, para controlar a alocação de recursos de forma justa, a Acme I.T. não deseja que nenhuma equipe ou linha de negócios do projeto tenha acesso de gerenciamento à infraestrutura dedicada subjacente. Além do mais, em conformidade com as auditorias de regulamentação, o Acme Management não deseja que o Acme I.T. possa acessar os dados que pertençam a diferentes equipes ou linhas de negócios do projeto; ou seja, os dados que eles armazenam em seus bancos de dados do aplicativo.
A AcmeHR, uma aplicação interna de RH desenvolvida e utilizada pela Acme, opera em dois ambientes distintos: um para desenvolvimento e teste (Dev) e outro para produção (Prod). A Acme I.T. tem o compromisso de manter um isolamento estrito entre esses ambientes para evitar qualquer acesso ou interação não autorizada entre as equipes de Desenvolvimento e Produção.
Recursos Necess
Componentes do OCI IAM
Descrição da ilustração Configure-adb-d-resource-isolation.png
-
Três compartimentos para fornecer isolamento de recursos, conforme descrito abaixo:
-
FleetComp para os recursos que o Acme I.T. cria, a rede e as sub-redes privadas usadas pelos bancos de dados de Desenvolvimento e Produção.
-
DevComp para o banco de dados de Desenvolvimento.
-
ProdComp para o banco de dados de Produção.
-
-
Três grupos aos quais os usuários podem ser atribuídos, um para usuários do Acme I.T., Dev e Prod. Esses grupos serão denominados FAGroup, DevGroup e ProdGroup.
-
Políticas necessárias para especificar o acesso do usuário aos recursos nos níveis de compartimento e tenancy.
Recursos de Rede
Descrição da ilustração configure-adbd-refarch-network.png
representa uma lista de segurança.
-
Implantações do Oracle Public Cloud:
-
Uma VCN para fornecer conectividade de rede a todos os recursos de infraestrutura dedicados. Essa VCN se conectará à VPN da Empresa Acme usando uma IPSec VPN e terá um recurso do Gateway de Internet que bloqueia todo o tráfego de entrada na internet. Ele será denominado AcmeHRVCN.
-
Três sub-redes para fornecer isolamento de acesso à rede, uma para os recursos do Autonomous AI Database dos ambientes Dev e Prod e outra para os recursos de cliente e camada intermediária do aplicativo. Essas sub-redes serão nomeadas DevVMSubnet, ProdVMSubnet e AppSubnet, respectivamente.
Observação: para simplificar, estamos usando uma única VCN e aproveitando sub-redes para fornecer isolamento de rede. No entanto, você também pode criar várias VCNs para fornecer o isolamento de acesso à rede necessário. Neste exemplo, criamos todas as três sub-redes: DevVMSubnet, ProdVMSubnet e AppSubnet em FleetComp para simplificar. Dependendo dos seus requisitos, você pode opcionalmente colocar essas sub-redes em compartimentos separados.
-
-
Implantações do Exadata Cloud@Customer:
-
Configure regras de rede conforme listado em Requisitos de Rede para o Oracle Exadata Database Service on Cloud@Customer em Preparando para o Exadata Database Service on Cloud@Customer.
-
Além disso, abra a Porta 1522 para permitir o tráfego TCP entre o banco de dados principal e o banco de dados stand-by em uma configuração do Autonomous Data Guard.
-
Recursos do Autonomous AI Database
Descrição da ilustração Configure-adb-d-resources.png
Recursos do Autonomous AI Database de acordo com a configuração mostrada acima.
-
Uma Infraestrutura Exadata para hospedar dois AVMCs. É denominado AcmeInfrastructure.
-
Dois AVMCs na AcmeInfrastructure para os ambientes de Desenvolvimento e Produção. Esses AVMCs são denominados DevAVMC e ProdAVMC, respectivamente.
-
DevAVMC:
-
Hospeda o Autonomous Container Database e os Autonomous AI Databases, que são denominados DevACD e DevADB, respectivamente, para desenvolver e testar o aplicativo AcmeHR.
-
Sempre corrigido para a última RU (atualização da versão).
-
Mantém sete (7) dias de backups.
-
Para cada Release Update (RU) ou patch release, o AcmeHR implantado no DevADB é testado com a RU mais recente.
-
Em caso de problemas críticos, um patch one-off é solicitado. Após a aplicação do patch one-off, o AcmeHR é novamente validado para garantir que o código seja estável e adequado para promoção à produção. Consulte Manutenção do Autonomous AI Database Service para saber mais sobre patches one-off.
-
-
ProdAVMC:
-
Hospeda o Autonomous Container Database e o Autonomous AI Database provisionados para implantação de produção do aplicativo AcmeHR. Elas são denominadas ProdACD e ProdADB, respectivamente.
-
Sempre executado na versão de software N-1.
-
Mantém backups por mais tempo. Se necessário, os backups de longo prazo também são ativados.
-
Trimestres alternativos corrigidos para o software validado, ou seja, as RUs validadas no DevAVMC são implantadas nesse banco de dados.
-
Etapas de Alto Nível
Antes que o Acme I.T. comece a configurar os recursos do Autonomous AI Database na Infraestrutura Dedicada do Exadata, ele solicita um aumento no limite de serviço usando a console do OCI para adicionar recursos do Exadata Infrastructure - Servidores de Banco de Dados e Servidores de Armazenamento à tenancy. Para obter mais detalhes, consulte Solicitar um Aumento do Limite de Serviço.
Veja a seguir as etapas de alto nível para implementar este caso de uso:
-
O administrador de segurança da tenancy em nuvem da Acme Company cria os seguintes compartimentos, grupos e políticas de compartimento para isolamento de recursos:
-
Os compartimentos FleetComp, DevComp e ProdComp.
-
Os grupos FAGroup, DevGroup e ProdGroup.
-
As políticas FleetCompPolicy, DevCompPolicy e ProdCompPolicy.
-
-
Para isolamento de acesso:
-
Para implantações do Oracle Public Cloud, o Acme I.T. ou o administrador de rede do Acme cria os seguintes recursos de rede no compartimento FleetComp:
-
VCN: AcmeHRVCN
-
Sub-redes privadas: DevVMSubnet e ProdVMSubnet
-
Sub-rede pública: AppSubnet
-
-
Para implantações do Exadata Cloud@Customer, o Acme I.T. ou o administrador de rede da Acme garante:
-
Configure regras de rede conforme listado em Requisitos de Rede para o Oracle Exadata Database Service on Cloud@Customer em Preparando o Exadata Database Service on Cloud@Customer.
-
Abra a Porta 1522 para permitir tráfego TCP entre o banco de dados principal e o banco de dados stand-by em uma configuração do Autonomous Data Guard.
-
-
-
Depois de criar recursos de rede, o administrador de segurança adiciona o usuário da nuvem de um membro designado do Acme I.T. ao FAGroup, autorizando assim esse usuário como administrador da frota.
-
O administrador de frota recém-autorizado cria os seguintes recursos de infraestrutura dedicados:
-
Um recurso AcmeInfrastructure da Infraestrutura do Exadata no compartimento FleetComp.
-
Dois Clusters de VMs do Autonomous Exadata (AVMCs) no compartimento FleetComp, especificando a Infraestrutura Exadata recém-criada:
-
DevAVMC.
Para implantações do Oracle Public Cloud, especifique AcmeHRVCN e DevVMSubnet como sua VCN e sub-rede.
-
ProdAVMC.
Para implantações do Oracle Public Cloud, especifique AcmeHRVCN e ProdVMSubnet como sua VCN e sub-rede.
-
-
-
Em seguida, o administrador de segurança adiciona usuários de nuvem designados aos ambientes DevGroup e ProdGroup, autorizando-os como DBAs de aplicativo para os ambientes Dev e Prod.
-
Os DBAs de aplicativos recém-autorizados criam os seguintes recursos em seus respectivos ambientes de trabalho, que são Dev e Prod:
-
Dois ACDs (Autonomous Container Databases):
-
DevACD no compartimento DevComp, especificando DevAVMC como seu recurso subjacente
-
ProdACD no compartimento ProdComp, especificando Prod AVMC como seu recurso subjacente.
-
-
O Autonomous AI Database chamado DevADB no compartimento DevComp.
-
O Autonomous AI Database chamado ProdADB no compartimento ProdComp.
-
Etapa 1. Criar Compartimentos
Nesta etapa, o administrador de segurança da tenancy em nuvem da Acme Company cria os compartimentos FleetComp, DevComp e ProdComp.
Para executar esta etapa, o administrador de segurança segue as instruções em Gerenciando Compartimentos na Documentação do Oracle Cloud Infrastructure para criar um compartimento usando a console do Oracle Cloud. Ao seguir essas instruções, o administrador de segurança especifica o compartimento raiz da tenancy como o compartimento pai de cada um dos três compartimentos.
Etapa 2. Criar Grupos
Nesta etapa, o administrador de segurança cria os grupos FAGroup, DevGroup e ProdGroup.
Para executar esta etapa, o administrador de segurança segue as instruções em Gerenciando Grupos na Documentação do Oracle Cloud Infrastructure para criar um grupo usando a console do Oracle Cloud.
Etapa 3. Criar Políticas
Nesta etapa, o administrador de segurança cria as políticas FleetCompPolicy, DevCompPolicy e ProdCompPolicy.
Para executar esta etapa, o administrador de segurança segue as instruções em Gerenciando Políticas na Documentação do Oracle Cloud Infrastructure para criar uma política usando a console do Oracle Cloud.
Observação: Além de criar as instruções da política necessárias, neste exemplo, o administrador de segurança também cria instruções da política "USE tag-namespaces" para permitir que os membros do grupo designem tags existentes aos recursos que eles criam. Para permitir que os membros de grupo criem tags, bem como usem tags existentes, o administrador de segurança criaria instruções da política "MANAGE tag-namespaces".
Ao seguir estas instruções para a política FleetCompPolicy, o administrador de segurança:
-
Define o Compartimento no menu lateral como FleetComp antes de clicar em Criar Política.
-
Adiciona uma das seguintes Declarações de Política, dependendo de sua plataforma de implantação:
-
Implantações do Oracle Public Cloud:
-
Permitir que o grupo FAGroup GERENCIE infraestruturas de metadados na nuvem no compartimento FleetComp
-
Permitir que o grupo FAGroup GERENCIE cloud-autonomous-vmclusters no compartimento FleetComp
-
Permitir que o grupo FAGroup USE virtual-network-family no compartimento FleetComp
-
Permitir que o grupo FAGroup USE namespaces de tag no compartimento FleetComp
-
Permitir que o grupo DevGroup LEIA infraestruturas de metadados na nuvem no compartimento FleetComp
-
Permitir que o grupo DevGroup LEIA cloud-autonomous-vmclusters no compartimento FleetComp
-
Permitir que o grupo DevGroup USE virtual-network-family no compartimento FleetComp
-
Permitir que o grupo ProdGroup LEIA infraestruturas de metadados na nuvem no compartimento FleetComp
-
Permitir que o grupo ProdGroup LEIA cloud-autonomous-vmclusters no compartimento FleetComp
-
Permitir que o grupo ProdGroup USE virtual-network-family no compartimento FleetComp
-
-
Implantações do Exadata Cloud@Customer:
-
Permitir que o grupo FAGroup GERENCIE infraestruturas exadata no compartimento FleetComp
-
Permitir que o grupo FAGroup GERENCIE autonomous-vmclusters no compartimento FleetComp
-
Permitir que o grupo FAGroup USE namespaces de tag no compartimento FleetComp
-
Permitir que o grupo DevGroup LEIA infraestruturas exadata no compartimento FleetComp
-
Permitir que o grupo DevGroup LEIA autonomous-vmclusters no compartimento FleetComp
-
Permitir que o grupo ProdGroup LEIA exadata-infrastructures no compartimento FleetComp
-
Permitir que o grupo ProdGroup LEIA autonomous-vmclusters no compartimento FleetComp
-
-
Ao seguir estas instruções para a política DevCompPolicy, o administrador de segurança:
-
Define o Compartimento no menu lateral como DevComp antes de clicar em Criar Política.
-
Adiciona estas Instruções de Política:
-
Permitir que o grupo DevGroup GERENCIE autonomous-container-databases no compartimento DevComp
-
Permitir que o grupo DevGroup GERENCIE autonomous-databases no compartimento DevComp
-
Permitir que o grupo DevGroup GERENCIE backups autônomos no compartimento DevComp
-
Permitir que o grupo DevGroup GERENCIE a família de instâncias no compartimento DevComp
-
Permitir que o grupo DevGroup USE namespaces de tag no compartimento DevComp
-
Permitir que o grupo DevGroup GERENCIE métricas no compartimento DevComp
-
Permitir que o grupo DevGroup INSPECT at work-requests no compartimento DevComp
-
Ao seguir estas instruções para a política ProdCompPolicy, o administrador de segurança:
-
Define o Compartimento no menu lateral como ProdComp antes de clicar em Criar Política.
-
Adiciona estas Instruções de Política:
-
Permitir que o grupo ProdGroup gerencie autonomous-container-databases no compartimento ProdComp
-
Permitir que o grupo ProdGroup gerencie autonomous-databases no compartimento ProdComp
-
Permitir que o grupo ProdGroup GERENCIE backups autônomos no compartimento ProdComp
-
Permitir que o grupo ProdGroup GERENCIE a família de instâncias no compartimento ProdComp
-
Permitir que o grupo ProdGroup USE tags-namespaces no compartimento ProdComp
-
Permitir que o grupo ProdGroup GERENCIE métricas no compartimento ProdComp
-
Permitir que o grupo ProdGroup INSPECT at work-requests no compartimento ProdComp
-
Etapa 4. Criar a VCN e Sub-redes
APLICA-SE A: 
Oracle Public Cloud somente
Nesta etapa, o Acme I.T. ou o administrador de rede da Acme cria a VCN AcmeHRVCN e as sub-redes DevVMSubnet, ProdVMSubnet e AppSubnet no compartimento FleetComp.
Para executar essa etapa, o IT da Acme primeiro confere à rede do departamento de IT da Acme uma faixa de endereços IP CIDR que não entrará em conflito com a rede local da empresa. (Caso contrário, a VCN entrará em conflito com a rede on-premises e não será possível configurar uma VPN IPSec.) O intervalo reservado é CIDR 10.0.0.0/16.
Em seguida, o Acme I.T. adapta as instruções no Cenário B: Sub-rede Privada com uma VPN na Documentação do Oracle Cloud Infrastructure para criar a VCN, as Sub-redes e outros recursos da rede usando a console do Oracle Cloud.
Neste exemplo, os seguintes blocos CIDR serão usados para as três (3) sub-redes na AcmeHRVCN:
-
Duas sub-redes privadas:
-
10.0.10.0/24 para DevVMSubnet
-
10.0.20.0/24 para ProdVMSubnet
-
-
Uma sub-rede pública:
- 10.0.100.0/24 para AppSubnet
Ao adaptar essas instruções, o Acme I.T. cria manualmente listas da segurança (em vez de usar as listas da segurança padrão) para isolar e separar as regras da segurança e, dessa forma, simplificar o gerenciamento da rede. Essas listas de segurança são:
-
DevSeclist: a lista de segurança básica para DevVMSubnet. Ela é usada quando a sub-rede DevVMSubnet é criada.
-
ProdSeclist: a lista de segurança básica para ProdVMSubnet. É usado quando a sub-rede ProdVMSubnet é criada.
-
AppSeclist: a lista de segurança básica para AppSubnet. Ela é usada quando a sub-rede AppSubnet é criada.
Para obter mais detalhes sobre os requisitos de entrada e saída do AVMC, consulte Requisitos para Provisionar um Cluster de VMs do Autonomous Exadata.
Regras de Segurança no DevSeclist
Estas são as regras de entrada criadas em DevSeclist:
| Sem Informações de Estado | Origem | Protocolo IP | Faixa de Portas de Origem | Faixa de Portas de Destino | Tipo e Código | Permite |
|---|---|---|---|---|---|---|
| No | 10.0.10.0/24 | ICMP | Tudo | Tudo | Tudo | Tráfego ICMP para: Todos |
| No | 10.0.10.0/24 | TCP | Tudo | Tudo | Tráfego TCP nas portas: Todas | |
| No | 10.0.100.0/24 | TCP | Tudo | 1521 | Tráfego TCP na porta: 1521 Oracle Net | |
| No | 10.0.100.0/24 | TCP | Tudo | 2484 | Tráfego TCPS para porta: 2484 Oracle Net | |
| No | 10.0.100.0/24 | TCP | Tudo | 6200 | ONS/FAN para portas: 6200 | |
| No | 10.0.100.0/24 | TCP | Tudo | 443 | Tráfego HTTPS para porta: 443 |
Estas são as regras de saída criadas em DevSeclist:
| Sem Informações de Estado | Destino | Protocolo IP | Faixa de Portas de Origem | Faixa de Portas de Destino | Tipo e Código | Permite |
|---|---|---|---|---|---|---|
| No | 10.0.10.0/24 | ICMP | Tudo | Tudo | Tudo | Todo o tráfego ICMP dentro do DevVMSubnet |
| No | 10.0.10.0/24 | TCP | Tudo | Tudo | Todo tráfego TCP na DevVMSubnet |
Regras de segurança em ProdSeclist
Observação: Mesmo que ProdSeclist tenha as mesmas regras de segurança que DevSeclist, o administrador de rede criou listas de segurança separadas, em vez de criar uma única lista de segurança para ambas as equipes de projeto para acomodar quaisquer regras de segurança adicionais necessárias para uma das equipes de projeto no futuro.
Estas são as regras de entrada criadas em ProdSeclist:
| Sem Informações de Estado | Origem | Protocolo IP | Faixa de Portas de Origem | Faixa de Portas de Destino | Tipo e Código | Permite |
|---|---|---|---|---|---|---|
| No | 10.0.20.0/24 | ICMP | Tudo | Tudo | Tudo | Tráfego ICMP para: Todos |
| No | 10.0.20.0/24 | TCP | Tudo | Tudo | Tráfego TCP nas portas: Todas | |
| No | 10.0.100.0/24 | TCP | Tudo | 1521 | Tráfego TCP na porta: 1521 Oracle Net | |
| No | 10.0.100.0/24 | TCP | Tudo | 2484 | Tráfego TCPS para porta: 2484 Oracle Net | |
| No | 10.0.100.0/24 | TCP | Tudo | 6200 | ONS/FAN para portas: 6200 | |
| No | 10.0.100.0/24 | TCP | Tudo | 443 | Tráfego HTTPS para porta: 443 |
Estas são as regras de saída criadas em ProdSeclist:
| Sem Informações de Estado | Destino | Protocolo IP | Faixa de Portas de Origem | Faixa de Portas de Destino | Tipo e Código | Permite |
|---|---|---|---|---|---|---|
| No | 10.0.20.0/24 | ICMP | Tudo | Tudo | Tudo | Todo o tráfego ICMP dentro do ProdVMSubnet |
| No | 10.0.20.0/24 | TCP | Tudo | Tudo | Todo o tráfego TCP dentro do ProdVMSubnet |
Regras de Segurança no AppSeclist
Esta é a regra de entrada criada em AppSeclist:
| Sem Informações de Estado | Origem | Protocolo IP | Faixa de Portas de Origem | Faixa de Portas de Destino | Tipo e Código | Permite |
|---|---|---|---|---|---|---|
| No | 0.0.0.0/0 | TCP | Tudo | 22 | Tudo | Tráfego SSH para portas: 22 |
Observação: é recomendável alterar 0.0.0.0/0 nas regras de segurança para sua lista aprovada de faixa de CIDRs/endereços IP.
Estas são as regras de saída criadas em AppSeclist:
| Sem Informações de Estado | Destino | Protocolo IP | Faixa de Portas de Origem | Faixa de Portas de Destino | Tipo e Código | Permite |
|---|---|---|---|---|---|---|
| No | 10.0.10.0/24 | TCP | Tudo | 1521 | ||
| No | 10.0.10.0/24 | TCP | Tudo | 2484 | ||
| No | 10.0.10.0/24 | TCP | Tudo | 443 | ||
| No | 10.0.10.0/24 | TCP | Tudo | 6200 | ||
| No | 10.0.20.0/24 | TCP | Tudo | 1521 | ||
| No | 10.0.20.0/24 | TCP | Tudo | 2484 | ||
| No | 10.0.20.0/24 | TCP | Tudo | 443 | ||
| No | 10.0.20.0/24 | TCP | Tudo | 6200 |
Etapa 5. Designar Administrador de Frota
Nesta etapa, o administrador da segurança adiciona ao FAGroup o usuário da nuvem de um membro designado do Acme I.T.
Para executar esta etapa, o administrador de segurança segue as instruções em Gerenciando Usuários na Documentação do Oracle Cloud Infrastructure para adicionar um usuário a um grupo usando a console do Oracle Cloud.
Etapa 6. Criar o Recurso Exadata Infrastructure
Nesta etapa, o administrador da frota segue as instruções em Criar um Recurso Exadata Infrastructure para criar um recurso Exadata Infrastructure chamado AcmeInfrastructure no compartimento FleetComp.
Etapa 7. Criar os Recursos de Clusters de VMs do Autonomous Exadata
Nesta etapa, o administrador da frota segue as instruções em Criar um Cluster de VMs do Autonomous Exadata para criar DevAVMC e ProdAVMC no compartimento FleetComp com as especificações a seguir, deixando todos os outros atributos em suas definições padrão.
| Definição | Ambiente de desenvolvimento | Ambiente de produção |
|---|---|---|
| Nome AVMC | DevAVMC | ProdAVMC |
| Infraestrutura Subjacente do Exadata | Infraestrutura Acme | Infraestrutura Acme |
| Rede virtual na nuvem (VCN) APLICA-SE A: Somente Oracle Public Cloud |
AcmeHRVCN | AcmeHRVCN |
| Sub-rede SE APLICA A: Somente Oracle Public Cloud |
DevVMSubnet | ProdVMSubnet |
Etapa 8. Designar DBAs do Aplicativo
Nesta etapa, o administrador de segurança adiciona usuários designados da nuvem ao DevGroup, autorizando-os como DBAs de aplicativo para os recursos de Desenvolvimento e, em seguida, repete o processo do ProdGroup.
Para executar essa etapa, para cada usuário, o administrador de segurança segue as instruções em Gerenciando Usuários na Documentação do Oracle Cloud Infrastructure para adicionar um usuário a um grupo usando a console do Oracle Cloud.
Etapa 9. Criar Recursos do Autonomous Container Database
Nesta etapa, os respectivos DBAs de aplicativos seguem as instruções em Criar um Autonomous Container Database para criar os Autonomous Container Databases (ACDs) para os ambientes Dev e Prod. Esses ACDs são criados com as seguintes especificações, deixando todos os outros atributos em suas configurações padrão.
| Definição | Ambiente de desenvolvimento | Ambiente de produção |
|---|---|---|
| Compartimento | DevComp | ProdComp |
| Nome ACD | DevACD | ProdACD |
| AVMC subjacente | DevAVMC | ProdAVMC |
| Versão do Software de Banco de Dados Contêiner | Versão mais recente do software (N) | Antecessor imediato da versão de software (N-1) |
| Versão de manutenção | Última RU (atualização da versão) | Próxima EF (atualização da versão) |
| Período de retenção do backup | 7 dias | 30 dias |
Etapa 10. Criar Recursos do Autonomous AI Database
Nesta etapa, os respectivos DBAs de aplicativos seguem as instruções em Criar um Autonomous AI Database para criar os Autonomous AI Databases para os ambientes Dev e Prod. Esses bancos de dados são criados com as seguintes especificações, deixando todos os outros atributos em suas configurações padrão.
| Definição | Ambiente de desenvolvimento | Ambiente de produção |
|---|---|---|
| Compartimento | DevComp | ProdComp |
| Nome do Banco de Dados | DevADB | ProdADB |
| ACD subjacente | DevACD | ProdACD |
| Instância de banco de dados | Pode optar por criar um Autonomous AI Database ou um Autonomous AI Database para Desenvolvedores | Autonomous AI Database |
O Autonomous AI Database na Infraestrutura Dedicada do Exadata agora está configurado para desenvolver e testar o aplicativo AcmeHR, com implantação subsequente no ambiente de produção.
Conteúdo Relacionado
Componentes do Autonomous AI Database na Infraestrutura Dedicada do Exadata