Pluggable Database Performance Profiles no Oracle Database 12c Release 2

Por Y V Ravi Kumar O ACE director, Rodrigo Mufalani Oracle ACE & Gavin Soorma Oracle ACE
Publicado en Julho 2017


Introdução:

Na versão anterior 12.1.0.2 do Oracle database, nós podíamos limitar a quantidade de utilização de CPU assim como a alocação Parallel Serversno nível do PDB através deResourcePlans.

Agora no Oracle 12c Release 2, nós podemos não somente regular a CPU e grau de paralelismo nos PDBs, mas também podemos restringir a quantidade de memória do PDB abrigada em um Container Database (CDB).

Além dissso, nós podemos limitar a quantidade de operações de I/O que cada PDB realiza, de modo que agora temos uma grande melhoria no trabalho do Resource Managergarantindo que nenhum PDB consuma toda a CPU disponível ou I/O porque talvez por uma query que rode para sempre que acabe impactando outros PDBs plugados no mesmo CDB.

Agora nós podemos limitar a quantidade de SGA e PGA que um PDB individual pode utilizar e garantir que certos PDBs terão garantidos seus níveis mínimos de memória em ambas PGA e SGA.

Por exemplo, agora podemos emitir SQL como esses abaixo conectado em um particular PDB que precisemos ajustar:

Parameter Description
SGA_TARGET Maximum SGA size for Pluggable Database (PDB)
SGA_MIN_SIZE Guaranteed SGA size for PDB
DB_CACHE_SIZE Guaranteed Buffer Cache size for PDB
DB_SHARED_POOL_SIZE Guaranteed Shared Pool size for PDB
PGA_AGGREGATE_LIMIT Maximum PGA size for PDB
PGA_AGGREGATE_TARGET Target PGA size for PDB

SQL> ALTER SYSTEM SET SGA_TARGET = 500M SCOPE = BOTH;

SQL> ALTER SYSTEM SET SGA_MIN_SIZE = 300M SCOPE = BOTH;

SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 200M SCOPE = BOTH;

SQL> ALTER SYSTEM SET MAX_IOPS = 10000 SCOPE = BOTH;

Outra nova funcionalidade do Oracle 12c Release 2 relacionada a arquiteruraMultitenant são os Performance Profiles.Com os Performance Profiles, nós podemos recuros de um grande número de PDBs especificando diretivas por profiles ao invés de cada PDB por vez.

Esses profiles são então alocados para o PDB através do parâmetro de inicialização:

DB_PERFORMANCE_PROFILE

Vamos ver um exemplo prático dos Performance Profiles.

Neste exemplo, nós temos 3 PDBs (PDB1, PDB2 e PDB3) plugados no container database CDB1. O pluggable database PDB1 abriga algumas aplicações de missão crítica e nós temos que garantir que o PDB1 tenhaa maiores recursos de memória compartilhada, como também I/O e não menos importante CPU comparado com o PDB2 e PDB3.

Então, vamos garantir essa alocação de recursos através de duas configurações de Performance Profiles – chamamos, neste caso, de TIER1 e TIER2.

Aqui estão os passos:

Criar uma PendingArea

SQL> exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA ();

PL/SQL procedure successfully completed.

Criar um CDB ResourcePlan

SQL> BEGIN
	DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
	plan   => 'profile_plan',
	comment => 'Performance Profile Plan allocating highest share of resources to PDB1');
            END;
           / 

PL/SQL procedure successfully completed.

Criar uma CDB resourceplandirective para os PDBs

O Performance profile Tier 1 garante que pelo menos 60% (3 shares) da CPU disponível e recursos de parallel server e sem limite máximo de uso de CPU ouparallel server execution. Em adição, ele garante que pelo menos 50% de alocação de memória disponível.

SQL> BEGIN
	DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
	plan                 => 'profile_plan',
	profile              => 'Tier1',
	shares               => 3,
	memory_min=> 50);
END;
/

 PL/SQL procedure successfully completed. 

Já o Performance profile Tier 2 é mais restritivo quanto a ter menos shares comparado ao Tier 1 e limitar a quantidade de uso de CPU/Parallel server a 40% assim como limitar a quantidade de memória ao nível de PDB a no máximo 25% da memória disponível.

 SQL> BEGIN
	DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
	plan                 => 'profile_plan',
	profile              => 'Tier2',
	shares               => 2,
	utilization_limit    => 40,
	memory_limit          => 25);
     END;
  /   

PL/SQL procedure successfully completed. 

Validar e Submitera Pending Area

SQL> exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SQL> exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

PL/SQL procedure successfully completed.

Alocar os Performance Profiles para os PDBs

O Performance Profile TIER1 é alocado para o PDB1 e o Performance Profile TIER2 é alocado para os pluggablesPDB2 e PDB3.

SQL> alter session set container=pdb1;

Session altered.

SQL> alter system set DB_PERFORMANCE_PROFILE='TIER1' scope=spfile;

System altered.

SQL> alter session set container=pdb2;

Session altered.

SQL> alter system set DB_PERFORMANCE_PROFILE='TIER2' scope=spfile;

System altered.

SQL> alter session set container=pdb3;

Session altered.

SQL> alter system set DB_PERFORMANCE_PROFILE='TIER2' scope=spfile;

System altered.

Configurar o Resource Plan no nível do CDB

SQL> conn / as sysdba
Connected.

SQL> alter system set resource_manager_plan='PROFILE_PLAN' scope=both;
System altered.

Configure o Performance Profileno nível dos PDBs

SQL> alter pluggable database all close immediate;

Pluggable database altered.

SQL> alter pluggable database all open;

Pluggable database altered.

Monitorando a utilização de memória no nível dos PDBs

A viewV$RSRCPDBMETRIC disponibiliza para nós as informações da quantidade de memória usada pelos PDBs.

Agora podemos ver que o PDB1 pertencente ao profile TIER1 tem quase o dobro de memória alocado nos outros dois PDBs no profile TIER2.

01

Conclusão:

Anteiormente, parametros de memória no nível do Container Database (CDB), controlavam configurações de memória para os for Pluggable Databases (PDBs), agora são aplicáveis ao nível dos PDBs, além dos novos parâmetros de de limite de memória.


Y V Ravi Kumar é um Oracle ACE e Oracle Certified Master (OCM) com 18 anos de experiência em instituições financeiras, serviços financeiros e seguros (BFSI) e atuou em diversos papeis como Senior Database Architect e Production DBA. Ele também é OCP em Oracle 8i, 9i, 10g, 11g & 12c e Certificado em Golden Gate, RAC, Performance Tuning& Oracle Exadata. Ele continua motivando muitos DBAs e ajudando a Oracle Community publicando suas dicas /ideias/sugestões/soluções em seu blog. Ele escreveu 40+ artigos OTN sobre Oracle Exadata, Oracle RAC e Oracle GoldenGate para a OTN em Espanhol, OTN em Português e OTN em inglês e 19 artigos para a TOAD World, 2 Artigos para o UKOUG, 3 Artigos para OTech Magazine e 2 Artigos para a Redgate. Ele é membro do AllIndia Oracle UserGroup (AIOUG) e frequente Oracle speaker in @NYOUG, @OTN, AIOUG, Sangam e IOUG. Ele desenha, projeta e implementa Core Banking System (CBS) Databases para o Central Banks em dois países – India e Mahe, Seychelles. Ele é Co-Founder do OraWorld (www.oraworld.com). Leia mais sobre o seu perfil na LaserSoft

Rodrigo Mufalani é um DBA Sr. com mais de 10 anos de experiência, começou com o Oracle 8i, mas teve a oportunidade de dar suporte a Oracle 7.3.4 em diante. É especialista em banco de dados Oracle com foco principal em Performance &Tuning e RAC. É palestrante em eventos de Oracle como: OTN LAD TOUR e outros. Atualmente trabalha como consultor diversas empresas no segmento de variados ramos como: Educação, Saúde, Tecnologia, Seguros e etc. Foi o terceiro Oracle ACE a ser nomeado no Brasil e é OCP DBA nas versões 10g e 11g. Atualmente trabalha na Mufalani. Twitter @mufalani / blog www.mufalani.com.br/blog

Gavin Soorma é um Oracle ACE, Oracle Certified Master (10g,11g and 12c), Oracle Certified Specialist (GoldenGate, Exadata 11g, Exadata Database Machine 2014) and Oracle OCP (8i to 12c)

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.