[oracle_br] Re: Duvida em DW

[jlchia...@yahoo.com.br [oracle_br]]

Bom, primeiro dá alguns esclarecimentos Importantes :

=> desses 96 GB, QUANTO vc já tem comprometido/usado pelas coisas afora a 
instância que vc está tunando (ie, Sistema Operacional, ASM, Clusterware, 
eventuais daemons/agentes/alikes que a Aplicação exige que estejam presentes 
no(s) servidore(s), outras Instâncias de menor criticidade)  Isso é 
CRÍTICO, de nada adianta vc ter 96 GB mas ter x% usado para outras coisas, a 
gente TEM que saber quanto está "livre" para direcionarmos na instância-alvo...

=>  vc diz que "Esta maquina" (singular) "tem 96 G de RAM", mas se é RAC de 3 
nós, vc tem que ter 3 máquinas... Cada nó é uma VM, e o servidor físico com 96 
GB, é isso ?? Se sim, QUANTO tem cada VM ??? Ou não é isso, vc Realmente tem 3 
servidores cada um com 96 GB ??

=> notar que "máquina" ABSOLUTAMENTE NÃO PEDE coisa alguma para "aumentar 
SGA+PGA" : o servidor em si é controlado pelo Sistema Operacional, que 
DESCONHECE o que é SGA ou PGA EU ** IMAGINO ** que na verdade é algum 
software na máquina que faz Recomendações de tuning que está fazendo essa 
Recomendação, confere ??? Sendo isso, Qual é o dito cujo ??
 De cara já Aviso que se o software em questão for o Advisor da Oracle (seja 
acessado diretamente, seja acessado pelo OEM, não importa) ele é meio 
"burrinho", no sentido que ao detectar aumento de I/O ele já sai sugerindo 
aumentar SGA, sem levar muito em conta a utilização efetiva do cache... Isso é 
notável principalmente em ambientes DW, onde NECESSARIAMENTE vc está 
trabalhando com grandes volumes (que DE JEITO NENHUM cabem no cache, E onde 
full table scans - que bypassam cache - abundam) : o Advisor não tá nem aí, ele 
sai mesmo recomendando aumentar SGA, se vc for atrás dele num ambiente que não 
pode se aproveitar muito de cache, vc fica doidinho

=> SE vc Realmente for deixar as áreas de memória (especialmente a SGA, claro) 
num volume de dezenas de GB, a Oracle *** RECOMENDA *** que vc implemente 
Hugepages : a nota metalink "HugePages on Oracle Linux 64-bit" (Doc ID 
361468.1) é cristalina a respeito :

"Why Do You Need HugePages?

HugePages is crucial for faster Oracle database performance on Linux if you 
have a large RAM and SGA. If your combined database SGAs is large (like more 
than 8GB, can even be important for smaller), you will need HugePages 
configured. Note that the size of the SGA matters. Advantages of HugePages are:

 

Larger Page Size and Less # of Pages: Default page size is 4K whereas the 
HugeTLB size is 2048K. That means the system would need to handle 512 times 
less pages.
Reduced Page Table Walking: Since a HugePage covers greater contiguous 
virtual address range than a regular sized page, a probability of getting a TLB 
hit per TLB entry with HugePages are higher than with regular pages. This 
reduces the number of times page tables are walked to obtain physical address 
from a virtual address.
Less Overhead for Memory Operations: On virtual memory systems (any modern 
OS) each memory operation is actually two abstract memory operations. With 
HugePages, since there are less number of pages to work on, the possible 
bottleneck on page table access is clearly avoided.
Less Memory Usage: From the Oracle Database perspective, with HugePages, 
the Linux kernel will use less memory to create pagetables to maintain virtual 
to physical mappings for SGA address range, in comparison to regular size 
pages. This makes more memory to be available for process-private computations 
or PGA usage.
No Swapping: We must avoid swapping to happen on Linux OS at all Document 
1295478.1. HugePages are not swappable (whereas regular pages are). Therefore 
there is no page replacement mechanism overhead. HugePages are universally 
regarded as pinned.
No 'kswapd' Operations: kswapd will get very busy if there is a very large 
area to be paged (i.e. 13 million page table entries for 50GB memory) and will 
use an incredible amount of CPU resource. When HugePages are used, kswapd is 
not involved in managing them. See also Document 361670.1
"

Eu *** IMAGINO *** que é por isso (ie, por causa da incompatibilidade de 
hugepages com AMM (vide nota "HugePages and Oracle Database 11g Automatic 
Memory Management (AMM) on Linux" (Doc ID 749851.1) que o teu DBA desabilitou o 
gerenciamento automático de memória (ie, zerou o memory target)... Agora, e o 
resto do setup de hugepages, tá feito ?? Feito DIREITO  Aponte pra ele as 
notas metalink "HugePages on Linux: What It Is... and What It Is Not..." (Doc 
ID 361323.1) , "Shell Script to Calculate Values Recommended Linux HugePages / 
HugeTLB Configuration" (Doc ID 401749.1)e os links delas...

=> tipicamente, DW implica em UMA, ou em MUITO POUCAS sessões rodando SQLs 
mega-complexos, então pode valer a pena usar workspace management manual e 
manualmente setar sort_area_size / hash_area_size em valores superaltos, pode 
ser de grande uso Paralelismo (então um large cache maior pode ser útil) 

[oracle_br] Duvida em DW

[lmarinh...@yahoo.com.br [oracle_br]]

Boa tarde colegas,
 Estou com um problema aqui de performance que aconteceu desde que se mudaram 
alguns parâmetros.
 Esta maquina tem 96 G de RAM esta em um SO 64 BIT RED HAT 11g Enterprise 
Edition Release 11.2.0.4.0
 RAC em 3 nós. Houve um problema, pois a maquina começou a pegir para aumentar 
SG+PGA dai comuniquei ao pessoa DBA'INFRA   com isso eles mudaram a forma que 
estava e inclusvise ativaram ate um parametro supostamente esta depreciado no 
11g e não colocaram como AMM para gerir as memorias SGA+PGA. Alguém tem uma 
sugestão para isso? Segue abaixo 
 

 ANTES
 

 memory_max_target big integer 32G
 memory_target big integer 32G 
 sga_max_size  big integer 12384M
 sga_targetbig integer 0
 

 shared_pool_reserved_size big integer 88919244
 shared_pool_size  big integer 0
 pga_aggregate_target  big integer 0
 

 parallel_automatic_tuningboolean FALSE
 parallel_degree_policy   string  MANUAL
 parallel_io_cap_enabled  boolean FALSE
 parallel_max_servers integer 1600
 parallel_min_percent integer 0
 parallel_servers_target  integer 640
 parallel_threads_per_cpu integer 2
 

 DEPOIS
 memory_max_targetbig integer 0
 memory_targetbig integer 0
 sga_max_size big integer 38G
 sga_target   big integer 38G
 shared_pool_reserved_sizebig integer 429496729
 shared_pool_size big integer 8G
 pga_aggregate_target big integer 9G
 

 parallel_automatic_tuningboolean TRUE
 parallel_degree_policy   string  AUTO   
 parallel_io_cap_enabled  boolean FALSE
 parallel_max_servers integer 1200
 parallel_min_percent integer 10
 parallel_servers_target  integer 900
 parallel_threads_per_cpu integer 2
 

 Cumprimentos,
 LM
 

 

[oracle_br] Re: Grant DDL

[jlchia...@yahoo.com.br [oracle_br]]

Roda o script abaixo, no sqlplus conectado como um usuário Administrador, que 
vc verá o conjunto Completo de privilégios para um dado usuário - se quiser ver 
de todos é relativamente Trivial alterar para não filtrar por um usuário só...

 []s
 
   Chiappa
   
-- GRANTs/Permissions
set echo off
set verify off
set pages 
col granted_role form a28
col owner form a15
col table_name form a33
col privilege form a33
ACCEPT username  prompt 'Enter Username : '
PROMPT Roles granted to user
SELECT granted_role,admin_option,default_role
FROM dba_role_privs
WHERE grantee=UPPER('&username')
ORDER BY 1;
PROMPT Table Privileges granted to a user through roles
SELECT granted_role, owner, table_name, privilege
FROM ( SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER('&username')
   UNION
   SELECT granted_role
FROM role_role_privs
WHERE role in (SELECT granted_role
 FROM dba_role_privs WHERE grantee=UPPER('&username')
)
   ) roles, dba_tab_privs
WHERE granted_role=grantee
ORder by 1,2,3,4;
PROMPT System Privileges assigned to a user through roles
SELECT granted_role, privilege
FROM ( SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER('&username')
   UNION
   SELECT granted_role
FROM role_role_privs
WHERE role in (SELECT granted_role
 FROM dba_role_privs WHERE grantee=UPPER('&username')
)
   ) roles, dba_sys_privs
WHERE granted_role=grantee
 ORDER BY 1,2;
PROMPT Table privileges assigned directly to a user
SELECT owner, table_name, privilege
FROM dba_tab_privs
WHERE grantee=UPPER('&username')
ORDER BY 1,2,3;
PROMPT System privileges assigned directly to a user
SELECT privilege, admin_option
FROM  dba_sys_privs
WHERE grantee=UPPER('&username') ORDER BY 1;
undefine username
   
 

[oracle_br] Grant DDL

['Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br]]

Bom Dia,

Como descobrir os usuários que tem grant de DDL?

 

Grato,

Ednilson