Menu de navegação

[HitotuziParticipante]

Bom dia senhores(as)!

Instalei o Oracle 19c em um servidor e vou precisar criar várias instâncias para nele. tenho 30 GB de memória disponível, aloquei para instância “batman” 20GB, porém, tenho que instalar as instâncias  “superman” e “flash”. Utilizando o comando “dbca” iniciei a instalação da instância  “superman” e imaginei que só teria 10GB de memória disponível para alocar, porém o instalador permitiu alocar mais que isso aloquei 12GB para testar. Instalei depois a instância  “flash” e vi que continua permitindo alocar a quantidade que eu quiser dentro dos 30GB total do S.O.

Verifiquei os parâmetros sga_max_size e pga_aggregate_limit e pga_aggregate_target e eles estão setados e distribuídos baseados nos valores de memória que aloquei para cada instância que somados dá um valor maior que 30GB o valor físico real existente no servidor. Vamos as perguntas:

1. Como o Oracle vai gerenciar essa memória entre as 3 instâncias ? Vai ser de acordo com o uso de recurso de cada uma? Tipo se a instância “batman” estiver precisando de mais memória o sistema vai retirar das outras e direcionar mais para ela?

2. Devo desfazer a instalação e distribuir essa memória entre as 3 instâncias de maneira que totalize os 30GB?

Desde já agradeço atenção e ajuda!

[José Laurindo ChiappaModerador]

Buenas, tudo na tranquila ? Espero que sim…..
Primeira coisa : veja, qualquer que seja o Sistema Operacional e os outrs detalhes, é ÓBVIo que ** não é ** apenas e tão somente o RDBMS Oracle que roda no servidor : TEM que rodar um Sistema Operacional, no mínimo…. Então, SE esses seus “30 GB de RAM disponível” são o TOTAL FÌSICO DE RAM no servidor, please NÃO RESERVE toda a RAM física só pro Oracle!!! Dependendo do Sistema Operacional e do que mais rode nesse servidor, vc VAI precisar reservar uma boa porção de RAM alocada pro Sistema Operacional e suas necessidades E pra outros softwares (como device drivers, middleware, etc) também presentes…. Uma conta DE PADEIRO, bem genérica, que se costuma fazer é alocar pra(s) instância(s) Oracle um total de 80% da RAM física, ficando os demais 20% pra Sistema Operacional e outros softwares….

Isso observado, aí é o seguinte : DESDE a versão 12c, a Oracle introduziu uma NOVA aqruitetura, a chamada arquitetura MULTI-TENANT : com ela, vc cria UMA e apenas UMA instância, E essa instância pode controlar vários databases, que são os chamados PLUGGABLE DATABASES (PDBs) – trata-se de databases Oracle comuns, que PODEM ter QUAISQUER configurações completamente diferentes entre si, sem problemas – aí com isso, vc indicaria PARA CADA UM dos seus DATABASEs o quanto de RAM que vc quer que O DATABASE use, E essa única instância VAI gerenciar tudo absolutamente direitinho, vide https://oracle-base.com/articles/12c/multitenant-memory-resource-management-for-pdbs-12cr2 … E um ponto, eu era muito Desconfiado de eventuais problemas de performance/concorrência com essa modernagem de UMA só instância controlar vários databases mas queimei a língua, isso foi Muito Bem programado pela Oracle, funciona muito bem, E (claro) vc PODE controlar o uso de recursos da instãncia única por parte dos múltiplos databases, EVITANDO que um SQL ruim/malfeito que ATOLE um dos databases consuma todos os recursos da instância, vide o Oracle Resource Manager em https://docs.oracle.com/en/database/oracle/oracle-database/18/multi/using-oracle-resource-manager-for-pdbs-with-sql-plus.html#GUID-19400E80-882F-424F-A19A-9FEB54F83577 , E leia o artigo em http://www.oracle.com/technetwork/database/multitenant/overview/multitenant-wp-12c-2078248.pdf relatando as Muitas vantagens e opções de controle/separação de CADA database num multitenant….

==> PORÉM, se CASO por algum motivo esdrúxulo estranhamente a sua Aplicação não permita multi-tenant e assim vc PRECISE MESMO criar várias instâncias para controlar vários databases, aí seguem as respostas :

• quando vc usa o DBCA (DataBase Creation Assistent) para criar uma instância E o database controlado por essa instância, o Assistente NÂO FAZ ABSOLUTAMENTE NENHUM CONTROLE dos recursos que vc já tenha eventualmente alocados, ele NÃO leva em conta se vc tem outras instâncias ou não (então SIM, como vc diz se vc criar 3 instãncias, onde a soma da RAM das 3 Ultrapassa a RAM física disponível ele VAI PERMITIR), ele NÂO LEVA EM CONTA se quanto Efetivamente da RAM presente está em uso ou está livre…
  Nem preciso dizer, é ÓBVIO que na hora que vc for tentar subir essas instãncias que no total usam mais RAM do que o que existe, vc VAI TER PROBLEMAS GRANDES, desde o Sistema ficar usando área de swap feito um louco até simplesmente dar pau/a instãncia não subir : é COMPLETAMENTE POR CONTA do DBA validar se as sugestões de alocação de recurso do dbca são factíveis ou não…

• o Oracle *** não *** “gerencia a memória entre as N instâncias” : quando vc starta uma instância o que ele faz é simplesmente pedir pro Sistema Operacional alocar o valor inicial de SGA e de PGA que vc indicou e é isso : SE uma das instãncias está mal-configurada e tentar alocar MAIS do que o permitido, simplesmente o Sistema Operacional vai falhar na alocação e o Oracle vai te dar uma mensagem de falha no startup, simples assim….
  E Absolutamente Não, NÂO EXISTE esse conceito de ‘gerenciar RAM entre as N instâncias’ : não, se uma instãncia muito Ativa ficou sem memória a alocar ele NÃO VAI retirar RAM de outra, não… É COMPLETAMENTE POR CONTA DO DBA estabelecer valores Adequados para cada database a ser controlado por CADA instãncia….

=> Não foi o que vc perguntou, mas só um Lembrete : já há várias versões, dentro de CADA DATABASE Oracle vc pode setar MEMORY_TARGET e /ou MEMORY_MAX_TARGET (que são as quantidades de memória DESEJADAS (target) e a máxima a alocar, já incluindo SGA+PGA) , OU pode setar separadamente SGA_TARGET / SGA_MAX_SIZE / SGA_MIN_SIZE e/ou PGA_AGGREGATE_LIMIT/PGA_AGGREGATE_TARGET .
A questão aqui é que SE vc indicou um TARGET de memória menor que o máximo, o Oracle vai tentar usar esse limite, só alocabdo mais (até o valor máximo) se realmente necessário mas assim que possível Voltando ao valor desejado…
O que NÃO VAI ACONTECER é RAM alocada para um database ser desalocada e alocada para OUTRO database, por mais que esse outro database esteja ativamente sendo usado e necessário…

• não, NÃO é necessário RE-INSTALAR NADA se vc quiser mudar configurações de uma instãncia que controle um database : basta vc alterar os parâmetros de MEMORY, SGA e PGA cfrme necessário…. Repito, porém, que é POR CONTA DO DBA fazer os cálculos de modo que a SOMA TOTAL das alocações em todas as instâncias não ultrapasse o máximo de RAM livre disponível, E que HAJA RAM extra livre disponível para os usos do Sistema Operacional e dos outros softwares presentes no servidor….

Abraços,

Chiappa

[HitotuziParticipante]

Bom dia Chiappa!

Tudo na paz? Muito obrigado pelos esclarecimentos, vou fazer o laboratório e testar o PLUGGABLE DATABASE (PDB), caso não atenda as minhas aplicações e eu tenha que criar instâncias separadas, seria mais aconselhável criar um listener para cada uma?  Outra coisa, é possível alocar um IP diferente para cada uma dessas instâncias mesmo estando no mesmo servidor criando placas de rede virtuais? Você já fez ou viu algo nesse sentido?

 

[José Laurindo ChiappaModerador]

Blz ? Então, sobre o LISTENER, o ponto é que, como ele só trabalha na hora que alguém tenta conectar no banco de dados ( o trabalho do listener é só e apenas direcionar o pedido de conexão para uma conexão que ou VAI ser criada na hora ou Já Existe num pool), DIFICILMENTE um listener é tão exigido que fique sobrecarregado, normalmente não é preciso criar vários não, A NÃO SER que vc preveja uma “tempestade de conexões”, ie, dúzias e dúzias de sessões querendo se conectar exatamente ao Mesmo tempo….
Já sobre IPs, é o seguinte : NEM um database Oracle NEM uma instância Oracle controlam e/ou precisam do IP para funcionarem, não…. Algumas tools Oracle AUXILIARES e/ou alguns outros softwares Oracle (como ENTERPRISE MANAGER, Clusterware, etc) sim, PRECISAM de um IP específico mas o RDBMS ORACLE em si, numa configuração stand-alone, não tá nem aí pra IPs, em tese ele por si só poderia até rodar num servidor SEM REDE ALGUMA….
Quem precisa de IP é O LISTENER em si, E as máquinas-cliente que FOREM se conectar no banco via Listener, o Listener TEM que ser alcançado ou por um hostname que possa ser convertido pra IP OU por um IP diretamente….
Isso bem entendido, é o seguinte : vc até PODE, sim, fazer um listener poder ser acessado por Múltiplos IPs , tipo colocando no arquivo de configuração LISTENER.ORA entrada :

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.52)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.53)(PORT = 1521))
)
)

==> https://www.mirsayeedhassan.com/configure-multiple-ip-address-with-single-default-port-1521/ exemplifica.. OK ??? E isso vale TANTO pra um listener que atenda uma só instância que controle N databases (a arquitetura multi-tenant) QUANTO pra um listener que atenda multiplas instâncias que controlam multiplos databases….

Agora : se vc Realmente precisar ter multiplas instâncias E se por qquer motivo vc quiser ter um listener atendendo cada instância, fique CIENTE que a restrição é que CADA LISTENER teria que estar atendendo à uma porta diferente, além de IP diferente….Isso respeitado ok, funcionaria sem problemas….

[HitotuziParticipante]

Boa tarde Chiappa!

Clareou bastante muito obrigado, hoje comecei fazer o laboratório com o PLUGGABLE DATABASE (PDB), li o artigo que vc me enviou estou tentando entender a dinâmica dessa funcionalidade, e como vou erenciá-la no meu dia-a-dia. A necessidade de múltiplas instâncias no mesmo servidor é que compramos licenças enterprise mas a grana não deu para abranger a quantidade necessária, temos uma máquina robusta com bastante capacidade de processamento e memória mas tivemos que readequar uma VM mediante a quantidade de licenças que obtivemos para usar os recursos dos processadores e não fugir da legalidade quanto as regras da Oracle na relação qdt de cores x licença. Assim temos que migrar todos os bancos de produção de variados sistemas que anteriormente estavam em VM separadas para essa VW que tem todas licenças adequadas a quantidades de cores.

As funcionalidade do PLUGGABLE DATABASE (PDB) em teroria seria o ideal,ter um conteiner com todos os os databases, podendo controlá-los de lá..  é o que estou testando, fico com um pouco de receio pois são bancos de produção e esse é meu primeiro contato com essa arquitetura multi-tenant. Você acha que o PLUGGABLE DATABASE (PDB) é a melhor solução para meu cenário?

1 abraço,

Hitotuzi

[José Laurindo ChiappaModerador]

Blz ? Então, vamos começar reconhecendo o elefante na sala : eu NÃO SOU especialista em Licenciamento Oracle, vc DEVERIA MESMO se tiver qquer dúvida consultar Empresas especializadas como http://www.beg.inf.br/beg/index.php/licencas-de-software-oracle, https://www.dbacorp.com.br/bancos-de-dados/licenciamento/, https://4matt.com.br/ , a a2f em https://www.bancodedadosoracle.com.br/ , a v8 consulting em https://www.v8consulting.com.br/ E várias outras, inclusive gringas) MAS ATÉ ONDE SEI se vc está licenciando por HARDWARE, ie, licenciando o SERVIDOR FÍSICO INTEIRO, com todos os processadores / sockets que o servidor tem, vc PODE SIM ter quantas instâncias quiser nesse servidor, POIS o servidor já está licenciado : https://dataunique.com.br/blog/17-perguntas-e-respostas-rapidas-sobre-licenciamento-oracle-que-voce-precisa-saber/ dis isso diretamente, https://ueno.com.br/blog/licenciamento-oracle/ também, https://community.oracle.com/tech/developers/discussion/4091699/how-many-database-instances-can-we-install-with-processor-based-license também, E ESSA tem sido a minha experiência, historicamente falando… Sendo assim, NÃO FAÇO IDÉIA qdo que vc quer dizer quando fala de “quantidade de licenças necessárias”, SE vc tá licenciando o servidor E comprou uma licença contabilizando TODOS os processadores pronto, tá tudo bem… E ABSOLUTAMENTE NÃO IMPORTA pra fins de licenciamento, UMA VEZ que vc licenciou TODOS os processadores, se vc vai rodar VMs ou não….. TALVEZ o que vc queira ter dito com esse negócio de ‘quantidade de licenças’ é que vc queria fazer HARD-PARTITIONING, ie, licenciar por processador MAS não todos os processadores, só alguns : tipo, isso é permitido DESDE QUE vc esteja usando o Oracle VM ou alguma solução de VM ACEITA PELA ORACLE , como mostrado em https://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf , aí a VM#1 que usa, digamos, 2 processadores teria uma licença X, a VM#2 que usa um só teria uma licença Y…. Aí sim…. PORÉM, isso vale a pena quando NO MOMENTO vc não quer licenciar a capacidade TOTAL dos processadores – se na verdade vc QUER licenciar todos os processadores, eu realmente DUVIDO que a SOMA do preço total das N licenças para cada hard-partition seja assim tão inferior ao licenciamento TOTAL que já te daria o direito de usar o servidor de uma vez, com QUANTAS INSTÂNCIAS vc quiser…. Bom, veja lá…

Feita a Ressalva de licenciamento, vamos voltar à minha área de expertise : SIM, tecnicamente falando eu acho SIM que multi-tenant seria o melhor pro seu caso, pois como eu disse essa Feature foi muito bem programada e implementada, já tem bem uns 5 anos de vida e está só progredindo a cada release, já vi ser bastante usada, sem grandes problemas, EM ESPECIAL sendo uma versão de Oracle que ainda está em Suporte pleno, como a 18c ou a 19c ou a 21c….

E detalhe importante, que PODE interferir aí com suas contas no que tange à licenciamento : no 19c, cfrme https://blogs.oracle.com/database/oracle-database-19c-up-to-3-pdbs-per-cdb-without-licensing-multitenant-v2 mostra, vc PODE TER ATÉ 3 PDBs ** sem ** pagar taxa extra de licença alguma …. NOVAMENTE, faça as contas de quanto custaria uma licença Enterprise full pra todos os seus processadores E da conveniência de vc poder ter teus 3 databases CONSOLIDADOS certinho SEM PAGAR NADA A MAIS POR ISSO versus o quanto vc paga tendo que licenciar 3 VMs diferentes com hard-partitioning…..

[]s

Chiappa

[HitotuziParticipante]

Bom dia Chiappa!

Mais uma vez obrigado pelas valiosas dicas e esclarecimentos. Infelizmente não conseguimos licenciar o servidor todo, segundo um consultor da Oracle que nos ajudou, seria necessário obter mais licenças para deixar toda a máquina licenciada mediante a capacidade de processadores que ela possui. Daí a solução que ele sugeriu foi criar uma Oracle VM disponibilizando a quantidade de processadores que abrangesse a quantidade de licenças que compramos. Se utilizássemos toda a capacidade do servidor estaríamos operando de  forma ilegal mediante a quantidade de licenças que compramos segundo o mesmo.  Enfim… vou continua o laboratório com o PLUGGABLE DATABASE (PDB) conforme sua sugestão, parece ser a melhor opção. Vou postar aqui depois o resultado e um resumo do que fiz e minhas impressões para caso tenha outro colega(s) na mesma situação, dá uma clareada para ele(s) também.

1 abraço,

Hitotuzi

[José Laurindo ChiappaModerador]

Só complementando : na verdade, se vc fosse licenciar o servidor todo vc NÃO IA comprar “mais licenças”, mas SIM uma única licença que já contasse TODOS os processadores, cores e threads, certo ?? Como esse valor dessa única licença integral ia ficar mais alto, aí vcs optaram por criar VMs que não usam todos os processadores mas só uma parte deles em cada VM, e adquirir uma licença pra cada VM, certo ??
Meu ponto é : IMAGINO que foi feita certinho a conta de quanto custaria UMA licença englobando todo o servidor físico, de quanto custaria no total as N licenças de todas as VMs E de quanto custaria uma licença pra só UMA VM que usasse todos os processadores que vc quer licenciar, E de quanto custam as x licenças para as x VMs criadas…. SE todas essas contas foram feitas certinho e te ofereceram a melhor opção, tá bom então….

Sobre o PDB, sim – faça seus testes direitinho e avalie….

[]s

Chiappa

[HitotuziParticipante]

Chiappa, boa tarde!

Quanto ao PDB, criei o containter (CDB)e coloquei nele 3 databases (PDB), constatei que automaticamente foram criados os tablespaces SYSTEM, SYSAUX, TEMP, UNDO tanto para o container, quanto para os 3 pluggable databases que estão dentro dele. Li uma documentação do Oracle 12c que diz existir apenas uma tablespace de UNDO para todo o CDB, ou seja, o tablespace de UNDO seria compartilhada entre os PDBs alocados nele. No 19c, não encontrei nada nesse sentido e como falei acima, foi criada uma tablespace UNDO para o próprio containter (CDB). A pergunta é, devo alocar o tamanho do tablespace UNDO individualmente para cada um dos 3 databases sem a necessidade de alterar o tablespace UNDO do container, ou eu devo somar o valor dos tablespaces UNDO dos 3 pluggable  databases  e alocar esse total no tablespace UNDO do container?
Ex.:

cenário A:

PDB1 undotbs = 10 GB

PDB2 undotbs = 10 GB

PDB3 undotbs = 10 GB

CDB  undotbs = 65 MEGABYTES (valor padrão da instalação)

cenário B:

PDB1 undotbs = 10GB

PDB2 undotbs = 10GB

PDB3 undotbs = 10GB

CDB  undotbs = 30GB

Desde já agradeço a ajuda

1 abraço

Hitotuzi

 

 

 

[José Laurindo ChiappaModerador]

Devagar aí, colega : realmente, https://oracle-base.com/articles/12c/multitenant-local-undo-mode-12cr2 já nos indica que , REALMENTE, no 12cR1 (que foi a versão INICIAL, o primeiro Esboço da arquitetura multitenant) SIM, era necessário que TODOS os PDBs COMPARTILHASSEM o mesmo UNDO criado no CDB , o chamado modo compartilhado/shared mode. NEM PRECISO DIZER, porém, que N coisas COMPARTILHANDO um único recurso é bem provável de dar ENROSCO, em especial com algo tão vital quanto o UNDO – assim sendo, a MESMA FONTE já nos alerta que a partir do 12.2 em diante o RECOMENDADO é o LOCAL UNDO, ie, cada database que crie o SEU próprio UNDO – assim, eu ACREDITO que a fonte da informação que vc leu deve estar simplesmente DEFASADA, as coisas progrediram MUITO depois do 12cR1… O MESMO LINK já avisa tambpem que Várias features / várias melhorias no gerenciamento de PDBs (vie https://www.thegeekdiary.com/undo-modes-in-12-2-multitenant-databases-local-and-shared-modes/) DEPENDEM do ter UNDO LOCAL, isso é Ainda Outra Coisa que Fortalece a recomendação de cada database ter o seu UNDO…

Sendo assim, a sua resposta é clara : vc VAI criar pra CADA DATABASE o undo do tamanho que ESSE database vai consumir/precisar, é algo ABSOLUTAMENTE PARTICULAR pra cada database, não tem relação NENHUMA com quantos outros databases vc tenha…
==> Minha recomendação inicial, SE vc não faz idéia do quanto cada database vai/pode precisar, é vc deixar os valores default E ir monitorando o quanto está sendo usado de undo, se o tempo de retenção está sendo suficiente ou se vc está recebendo e vez em quanto snapshot too oldo CDB controla, enfim, o procedimento NORMAL de administração de um database Oracle…

ALIÁS, essa é AINDA OUTRA vantagem de UNDO em modo LOCAL, vc passa a controlar as necessidades de undo de cada database DE MODO INDEPENDENTE, sem ter que levar em conta os outros, vc só vai se preocuparcom TOTAL de espaço em disco, atuando para que uma tablespace de undo de um database não cresça tanto que interfira no espaço em disco TOTAL que todo mundo precisa usar….

[]s

Chiappa

[HitotuziParticipante]

Bom dia Chiappa!

Entendi, imaginei que a ferramenta tinha progredido mesmo… Já sei o quanto cada um PDB vai necessitar para seus respectivos UNDOs vai ser mais tranquilo,  vou fazer as implementações e começar o import, obrigado pelas dicas e pelos links.

1 abraço,

Hitotuzi

[José Laurindo ChiappaModerador]

Blz… Pra te ajudar, algumas dicas mais :

1. os N databases VÃO compartilhar alguns recursos do servidor, como espaço em disco, CPUs, capacidade de I/O : assim, recomendo vc desde o começo já pensar em LIMITAR os recursos, por exemplo Não Deixando as tablespaces aumentarem sozinhas sem limite, setando memória LEVANDO EM CONTA as necessidades de cada database no total, E avaliando a possibilidade de usar o resource management, vide no manual “Database 2 Day DBA” da sua versão o capítulo ‘Using Resource Manager to Create CDB and PDB Resource Plans’, ou então outras funcionalidades de separação/lock de databases, tal como os Lockdown profiles em https://blogs.oracle.com/database/a-simple-guide-to-lockdown-profiles-v2 , https://www.oracle.com/br/technical-resources/articles/idm/usando-lockdown-profile.html e https://oracle-base.com/articles/12c/multitenant-pdb-lockdown-profiles-12cr2
2. considere ativar/usar o recurso do UNDO temporário, vide https://databaseinternalmechanism.com/oracle-12c-miscellaneous/12c-new-features-global-temporary-table-undo/ , https://oracle-base.com/articles/12c/temporary-undo-12cr1 e a sua Documentação
3. cada PDB é um database logicamente COMPLETO, então vc ainda Pode usar as mesmas views E os mesmos advisors (SE vc tiver acesso à eles) de sempre pra monitorar temp area, undo/rollback, memória, etc…

Ok ? Qquer dúvida manda uma msg aí, que tentamos te ajudar no ponto específico…

[]s

Chiappa

[DaryelParticipante]

Chiappa, boa tarde,

Quero lhe agradecer pelo conhecimento repassado, comecei a atuar com Oracle há pouco tempo e consegui montar o ambiente de produção com 1 CDB e 3 PDB’s muito mais rápido que imaginava, não é a primeira vez que vejo respostas suas em fóruns e são sempre completas, com referências às documentações e com ótima didática.

Obrigado.

[José Laurindo ChiappaModerador]

Parabéns por ter conseguido rapidamente e com precisão / eficiência o seu Objetivo, Fico Muito contente de poder ter te ajudado….

Abraços,

Chiappa

[Autor]

Posts