Re: RES: RES: [oracle_br] URGENTE - SGA x PGA

2013-02-05 Por tôpico ederson2001br 
Alô Samuel,

Bem, começou a melhorar, boas possibilidades.

Veja, se vc está fazendo um select que insere em uma outra tabela, o tempo de 
processamento conta com a finalização do SQL para transferência de controle 
para o insert, supondo que exista uma estrutura INSERT INTO tab1 SELECT ?? 
from A, B, C, n where  OK?

Veja, na TAB1, existem indices? Existem triggers de BEFORE/AFTER insert? vc já 
verificou o seu plano de execução para ver se há full scan em alguma tabela? vc 
está usando cursores com loop neste carga.sql? Tudo isto onera na performance.

Caso não tenha feito, verifique o plano de execução primeiro, pode ser até com 
o explain plan no SQLPLUS. Passo dois: ao invés de insert into, faça CTA que é 
mais vantajoso. Veja dicas neste link 
http://www.dba-oracle.com/t_create_table_select_ctas.htm 


Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0




--- Em oracle_br@yahoogrupos.com.br, Samuel Santos  escreveu
>
> A carga é realizada através de QUERY(JOINs) e inseridos em tabelas(físicas), 
> que se encontra na mesma instância.
> 
> Quanto ao SQLDR(sql loader), neste momento é praticamente impossível neste 
> momento. O script é executado diretamente no servidor, acessando-o através do 
> SQLPlus (@carga.sql).
>  
> Atenciosamente,
> 
> Samuel Geraldo dos Santos
> 
> 
> 
> >
> > De: Vitor Jr. 
> >Para: oracle_br@yahoogrupos.com.br 
> >Enviadas: Terça-feira, 5 de Fevereiro de 2013 17:42
> >Assunto: RES: RES: [oracle_br] URGENTE - SGA x PGA
> > 
> >
> >  
> >Já começa por aí... com essa quantidade de memória eu seguramente estaria 
> >usando HugePages (necessita confg no s.o.) em conjunto com os parâmetros que 
> >citei setados para true + utilização do automatic shared memory management e 
> >do automatic PGA management, visto que não conheço a aplicação estrutura 
> >para setar manualmente os parâmetros de memória...
> >
> >Att
> >
> >Vitor Jr
> >
> >De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em 
> >nome de Samuel Santos
> >Enviada em: terça-feira, 5 de fevereiro de 2013 17:35
> >Para: oracle_br@yahoogrupos.com.br
> >Assunto: Re: RES: [oracle_br] URGENTE - SGA x PGA
> >
> >Segue novas informações, para que se puderem me ajudar a ajustar este 
> >servidor.
> >Muito Obrigado.
> >
> >grep Huge /proc/meminfo
> >
> >HugePages_Total: 0
> >HugePages_Free:  0
> >HugePages_Rsvd:  0
> >Hugepagesize: 2048 kB
> >
> >SQL> show parameter lock_sga
> >
> >NAME TYPEVALUE
> > --- 
> >--
> >lock_sga boolean FALSE
> >SQL>
> >SQL> show parameter pre_page_sga
> >
> >NAME TYPEVALUE
> >------------------------ --- 
> >--
> >pre_page_sga boolean FALSE
> >
> >>
> >> De: Vitor Jr. vitorjr81@... >
> >>Para: oracle_br@yahoogrupos.com.br 
> >>Enviadas: Terça-feira, 5 de Fevereiro de 2013 17:22
> >>Assunto: RES: [oracle_br] URGENTE - SGA x PGA
> >> 
> >>
> >> 
> >>Rafael, no caso da quantidade de memória envolvida o AMM não me parece o 
> >>mais indicado.
> >>
> >>Citando:
> >>
> >>When you have large SGA sizes you can get considerable benefits from using 
> >>http://www.oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64.php>
> >> HugePages. Automatic Memory Management and HugePages on Linux are not 
> >>compatible, which means AMM is probably not a sensible option for any large 
> >>systems. Instead, 
> >>http://www.oracle-base.com/articles/10g/performance-tuning-enhancements-10g.php#automatic_shared_memory_management>
> >> Automatic Shared Memory Management and 
> >>http://www.oracle-base.com/articles/9i/memory-management-9i.php#AutomaticSQLExecutionMemoryManagement>
> >> Automatic PGA Management should be used as they are compatible with 
> >>HugePages.
> >>
> >>http://www.oracle-base.com/articles/11g/automatic-memory-management-11gr1.php
> >>
> >>Samuel, é muito mais complexo que esses parâmetros apenas que tu passou, 
> >>por exemplo, tem hugepages configurado nesse servidor? Os parâmetros de 
> >>banco lock_sga e pre_page_sga como estão?
> >>
> >>Ainda, recomendo alguma

Re: RES: RES: [oracle_br] URGENTE - SGA x PGA

2013-02-05 Por tôpico Samuel Santos 
A carga é realizada através de QUERY(JOINs) e inseridos em tabelas(físicas), 
que se encontra na mesma instância.

Quanto ao SQLDR(sql loader), neste momento é praticamente impossível neste 
momento. O script é executado diretamente no servidor, acessando-o através do 
SQLPlus (@carga.sql).
 
Atenciosamente,

Samuel Geraldo dos Santos



>
> De: Vitor Jr. 
>Para: oracle_br@yahoogrupos.com.br 
>Enviadas: Terça-feira, 5 de Fevereiro de 2013 17:42
>Assunto: RES: RES: [oracle_br] URGENTE - SGA x PGA
> 
>
>  
>Já começa por aí... com essa quantidade de memória eu seguramente estaria 
>usando HugePages (necessita confg no s.o.) em conjunto com os parâmetros que 
>citei setados para true + utilização do automatic shared memory management e 
>do automatic PGA management, visto que não conheço a aplicação estrutura para 
>setar manualmente os parâmetros de memória...
>
>Att
>
>Vitor Jr
>
>De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
>de Samuel Santos
>Enviada em: terça-feira, 5 de fevereiro de 2013 17:35
>Para: oracle_br@yahoogrupos.com.br
>Assunto: Re: RES: [oracle_br] URGENTE - SGA x PGA
>
>Segue novas informações, para que se puderem me ajudar a ajustar este servidor.
>Muito Obrigado.
>
>grep Huge /proc/meminfo
>
>HugePages_Total: 0
>HugePages_Free:  0
>HugePages_Rsvd:  0
>Hugepagesize: 2048 kB
>
>SQL> show parameter lock_sga
>
>NAME TYPEVALUE
> --- --
>lock_sga boolean FALSE
>SQL>
>SQL> show parameter pre_page_sga
>
>NAME TYPEVALUE
> --- --
>pre_page_sga boolean FALSE
>
>>________
>> De: Vitor Jr. vitorj...@gmail.com >
>>Para: oracle_br@yahoogrupos.com.br 
>>Enviadas: Terça-feira, 5 de Fevereiro de 2013 17:22
>>Assunto: RES: [oracle_br] URGENTE - SGA x PGA
>> 
>>
>> 
>>Rafael, no caso da quantidade de memória envolvida o AMM não me parece o mais 
>>indicado.
>>
>>Citando:
>>
>>When you have large SGA sizes you can get considerable benefits from using 
>>http://www.oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64.php>
>> HugePages. Automatic Memory Management and HugePages on Linux are not 
>>compatible, which means AMM is probably not a sensible option for any large 
>>systems. Instead, 
>>http://www.oracle-base.com/articles/10g/performance-tuning-enhancements-10g.php#automatic_shared_memory_management>
>> Automatic Shared Memory Management and 
>>http://www.oracle-base.com/articles/9i/memory-management-9i.php#AutomaticSQLExecutionMemoryManagement>
>> Automatic PGA Management should be used as they are compatible with 
>>HugePages.
>>
>>http://www.oracle-base.com/articles/11g/automatic-memory-management-11gr1.php
>>
>>Samuel, é muito mais complexo que esses parâmetros apenas que tu passou, por 
>>exemplo, tem hugepages configurado nesse servidor? Os parâmetros de banco 
>>lock_sga e pre_page_sga como estão?
>>
>>Ainda, recomendo algumas notas:
>>
>>https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=401749.1
>> 
>>https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=401749.1&type=DOCUMENT&displayIndex=3>
>> &type=DOCUMENT&displayIndex=3> Shell Script to Calculate Values Recommended 
>>Linux HugePages / HugeTLB Configuration[Article ID 401749.1]
>>
>>https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=361323.1
>> 
>>https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=361323.1&type=DOCUMENT&displayIndex=5>
>> &type=DOCUMENT&displayIndex=5> HugePages on Linux: What It Is... and What It 
>>Is Not...[Article ID 361323.1]
>>
>>Nessa nota acima cito o seguinte tópico:
>>
>>Advantages of HugePages Over Normal Sharing Or AMM (see below)
>>
>>* Not swappable: HugePages are not swappable. Therefore there is no 
>>page-in/page-out mechanism overhead.HugePages are universally regarded as 
>>pinned.
>>* Relief of TLB pressure:
>>
>>* Hugepge uses fewer pages to cover the physical address space, so the size 
>>of “book keeping” (mapping from the virtual to the physical address) 
>>decreases, so it requiring fewer entries in the TLB
>>* TLB entries will cover a larger part of the address space when use 
>&g

RES: RES: [oracle_br] URGENTE - SGA x PGA

2013-02-05 Por tôpico Vitor Jr. 
Já começa por aí... com essa quantidade de memória eu seguramente estaria 
usando HugePages (necessita confg no s.o.) em conjunto com os parâmetros que 
citei setados para true + utilização do automatic shared memory management e do 
automatic PGA management, visto que não conheço a aplicação estrutura para 
setar manualmente os parâmetros de memória...

 

Att

Vitor Jr

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Samuel Santos
Enviada em: terça-feira, 5 de fevereiro de 2013 17:35
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] URGENTE - SGA x PGA

 

  

Segue novas informações, para que se puderem me ajudar a ajustar este servidor.
Muito Obrigado.

grep Huge /proc/meminfo

HugePages_Total: 0
HugePages_Free:  0
HugePages_Rsvd:  0
Hugepagesize: 2048 kB

SQL> show parameter lock_sga

NAME TYPEVALUE
 --- --
lock_sga boolean FALSE
SQL>
SQL> show parameter pre_page_sga

NAME TYPEVALUE
 --- --
pre_page_sga boolean FALSE

 

>
> De: Vitor Jr. vitorj...@gmail.com <mailto:vitorjr81%40gmail.com> >
>Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br>  
>Enviadas: Terça-feira, 5 de Fevereiro de 2013 17:22
>Assunto: RES: [oracle_br] URGENTE - SGA x PGA
> 
>
>  
>Rafael, no caso da quantidade de memória envolvida o AMM não me parece o mais 
>indicado.
>
>Citando:
>
>When you have large SGA sizes you can get considerable benefits from using 
>http://www.oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64.php>
> HugePages. Automatic Memory Management and HugePages on Linux are not 
>compatible, which means AMM is probably not a sensible option for any large 
>systems. Instead, 
>http://www.oracle-base.com/articles/10g/performance-tuning-enhancements-10g.php#automatic_shared_memory_management>
> Automatic Shared Memory Management and 
>http://www.oracle-base.com/articles/9i/memory-management-9i.php#AutomaticSQLExecutionMemoryManagement>
> Automatic PGA Management should be used as they are compatible with HugePages.
>
>http://www.oracle-base.com/articles/11g/automatic-memory-management-11gr1.php
>
>Samuel, é muito mais complexo que esses parâmetros apenas que tu passou, por 
>exemplo, tem hugepages configurado nesse servidor? Os parâmetros de banco 
>lock_sga e pre_page_sga como estão?
>
>Ainda, recomendo algumas notas:
>
>https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=401749.1 
><https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=401749.1&type=DOCUMENT&displayIndex=3>
> &type=DOCUMENT&displayIndex=3> Shell Script to Calculate Values Recommended 
>Linux HugePages / HugeTLB Configuration[Article ID 401749.1]
>
>https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=361323.1 
><https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=361323.1&type=DOCUMENT&displayIndex=5>
> &type=DOCUMENT&displayIndex=5> HugePages on Linux: What It Is... and What It 
>Is Not...[Article ID 361323.1]
>
>Nessa nota acima cito o seguinte tópico:
>
>Advantages of HugePages Over Normal Sharing Or AMM (see below)
>
>* Not swappable: HugePages are not swappable. Therefore there is no 
>page-in/page-out mechanism overhead.HugePages are universally regarded as 
>pinned.
>* Relief of TLB pressure:
>
>* Hugepge uses fewer pages to cover the physical address space, so the size of 
>“book keeping” (mapping from the virtual to the physical address) decreases, 
>so it requiring fewer entries in the TLB
>* TLB entries will cover a larger part of the address space when use 
>HugePages, there will be fewer TLB misses before the entire or most of the SGA 
>is mapped in the SGA
>* Fewer TLB entries for the SGA also means more for other parts of the address 
>space
>
>* Decreased page table overhead: Each page table entry can be as large as 64 
>bytes and if we are trying to handle 50GB of RAM, the pagetable will be 
>approximately 800MB in size which is practically will not fit in 880MB size 
>lowmem (in 2.4 kernels - the page table is not necessarily in lowmem in 2.6 
>kernels) considering the other uses of lowmem. When 95% of memory is accessed 
>via 256MB hugepages, this can work with a page table of approximately 40MB in 
>total. See also Document 361468.1 
>https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?id=361468.1> 
>.
>* Eliminated page tab

Re: RES: [oracle_br] URGENTE - SGA x PGA

2013-02-05 Por tôpico Samuel Santos 
Segue novas informações, para que se puderem me ajudar a ajustar este servidor.
Muito Obrigado.

grep Huge /proc/meminfo

HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB



SQL> show parameter lock_sga

NAME                                 TYPE        VALUE
 --- --
lock_sga                             boolean     FALSE
SQL>
SQL> show parameter pre_page_sga

NAME                                 TYPE        VALUE
 --- --
pre_page_sga                         boolean     FALSE

 



>
> De: Vitor Jr. 
>Para: oracle_br@yahoogrupos.com.br 
>Enviadas: Terça-feira, 5 de Fevereiro de 2013 17:22
>Assunto: RES: [oracle_br] URGENTE - SGA x PGA
> 
>
>  
>Rafael, no caso da quantidade de memória envolvida o AMM não me parece o mais 
>indicado.
>
>Citando:
>
>When you have large SGA sizes you can get considerable benefits from using 
>http://www.oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64.php>
> HugePages. Automatic Memory Management and HugePages on Linux are not 
>compatible, which means AMM is probably not a sensible option for any large 
>systems. Instead, 
>http://www.oracle-base.com/articles/10g/performance-tuning-enhancements-10g.php#automatic_shared_memory_management>
> Automatic Shared Memory Management and 
>http://www.oracle-base.com/articles/9i/memory-management-9i.php#AutomaticSQLExecutionMemoryManagement>
> Automatic PGA Management should be used as they are compatible with HugePages.
>
>http://www.oracle-base.com/articles/11g/automatic-memory-management-11gr1.php
>
>Samuel, é muito mais complexo que esses parâmetros apenas que tu passou, por 
>exemplo, tem hugepages configurado nesse servidor? Os parâmetros de banco 
>lock_sga e pre_page_sga como estão?
>
>Ainda, recomendo algumas notas:
>
>https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=401749.1&type=DOCUMENT&displayIndex=3>
> Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB 
>Configuration[Article ID 401749.1]
>
>https://support.oracle.com/epmos/faces/ui/km/SearchDocDisplay.jspx?id=361323.1&type=DOCUMENT&displayIndex=5>
> HugePages on Linux: What It Is... and What It Is Not...[Article ID 361323.1]
>
>Nessa nota acima cito o seguinte tópico:
>
>Advantages of HugePages Over Normal Sharing Or AMM (see below)
>
>*  Not swappable: HugePages are not swappable. Therefore there is no 
>page-in/page-out mechanism overhead.HugePages are universally regarded as 
>pinned.
>*  Relief of TLB pressure:
>
>*  Hugepge uses fewer pages to cover the physical address space, so the 
>size of “book keeping” (mapping from the virtual to the physical address) 
>decreases, so it requiring fewer entries in the TLB
>*  TLB entries will cover a larger part of the address space when use 
>HugePages, there will be fewer TLB misses before the entire or most of the SGA 
>is mapped in the SGA
>*  Fewer TLB entries for the SGA also means more for other parts of the 
>address space
>
>*  Decreased page table overhead: Each page table entry can be as large as 
>64 bytes and if we are trying to handle 50GB of RAM, the pagetable will be 
>approximately 800MB in size which is practically will not fit in 880MB size 
>lowmem (in 2.4 kernels - the page table is not necessarily in lowmem in 2.6 
>kernels) considering the other uses of lowmem. When 95% of memory is accessed 
>via 256MB hugepages, this can work with a page table of approximately 40MB in 
>total. See also Document 361468.1 
>https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?id=361468.1> 
>.
>*  Eliminated page table lookup overhead: Since the pages are not subject 
>to replacement, page table lookups are not required.
>*  Faster overall memory performance: On virtual memory systems each 
>memory operation is actually two abstract memory operations. Since there are 
>fewer pages to work on, the possible bottleneck on page table access is 
>clearly avoided. 
>
>De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
>de Rafael Mendonca
>Enviada em: terça-feira, 5 de fevereiro de 2013 17:07
>Para: oracle_br@yahoogrupos.com.br
>Assunto: Re: [oracle_br] URGENTE - SGA x PGA
>
>Porque vc não ativa o memory_target e deixa com que o Oracle se preocupe com 
>isso ? Já li alguns livros que a partir da versão 11G R2 o Oracle administra 
>as 2 memórias(SGA e PGA) muito melhor do que muito DBA expert por aí.
>
>
>De: Samuel Santos samuel.gsan...@y

RES: [oracle_br] URGENTE - SGA x PGA

2013-02-05 Por tôpico Vitor Jr. 
Rafael, no caso da quantidade de memória envolvida o AMM não me parece o mais 
indicado.

Citando:

 

When you have large SGA sizes you can get considerable benefits from using  

 HugePages. Automatic Memory Management and HugePages on Linux are not 
compatible, which means AMM is probably not a sensible option for any large 
systems. Instead,  

 Automatic Shared Memory Management and  

 Automatic PGA Management should be used as they are compatible with HugePages.

http://www.oracle-base.com/articles/11g/automatic-memory-management-11gr1.php

 

Samuel, é muito mais complexo que esses parâmetros apenas que tu passou, por 
exemplo, tem hugepages configurado nesse servidor? Os parâmetros de banco 
lock_sga e pre_page_sga como estão?

 

Ainda, recomendo algumas notas:

 

 Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB 
Configuration[Article ID 401749.1]

 

 HugePages on Linux: What It Is... and What It Is Not...[Article ID 361323.1]

 

Nessa nota acima cito o seguinte tópico:


Advantages of HugePages Over Normal Sharing Or AMM (see below)


*   Not swappable: HugePages are not swappable. Therefore there is no 
page-in/page-out mechanism overhead.HugePages are universally regarded as 
pinned.
*   Relief of TLB pressure:

*   Hugepge uses fewer pages to cover the physical address space, so the 
size of “book keeping” (mapping from the virtual to the physical address) 
decreases, so it requiring fewer entries in the TLB
*   TLB entries will cover a larger part of the address space when use 
HugePages, there will be fewer TLB misses before the entire or most of the SGA 
is mapped in the SGA
*   Fewer TLB entries for the SGA also means more for other parts of the 
address space

*   Decreased page table overhead: Each page table entry can be as large as 
64 bytes and if we are trying to handle 50GB of RAM, the pagetable will be 
approximately 800MB in size which is practically will not fit in 880MB size 
lowmem (in 2.4 kernels - the page table is not necessarily in lowmem in 2.6 
kernels) considering the other uses of lowmem. When 95% of memory is accessed 
via 256MB hugepages, this can work with a page table of approximately 40MB in 
total. See also Document 361468.1 
 
.
*   Eliminated page table lookup overhead: Since the pages are not subject 
to replacement, page table lookups are not required.
*   Faster overall memory performance: On virtual memory systems each 
memory operation is actually two abstract memory operations. Since there are 
fewer pages to work on, the possible bottleneck on page table access is clearly 
avoided.   

 

 

 

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Rafael Mendonca
Enviada em: terça-feira, 5 de fevereiro de 2013 17:07
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] URGENTE - SGA x PGA

 

  

Porque vc não ativa o memory_target e deixa com que o Oracle se preocupe com 
isso ? Já li alguns livros que a partir da versão 11G R2 o Oracle administra as 
2 memórias(SGA e PGA) muito melhor do que muito DBA expert por aí.


De: Samuel Santos samuel.gsan...@yahoo.com.br 
 >
Para: oracle_br oracle_br@yahoogrupos.com.br 
 > 
Enviadas: Terça-feira, 5 de Fevereiro de 2013 17:03
Assunto: [oracle_br] URGENTE - SGA x PGA


  
Pessoal, Boa Tarde!

Peço-lhes uma ajuda para solucionar um problema crítico de carga de dados no 
servidor de um cliente, segue as características do ambiente:

Modelo: DELL R710  - 2Us
S/T: B3Q82R1
2 Processadores Six-Core 2,40 GHZ
Memória 144G
2 HDs de 1T 
Servidor não possui placa HBA
Sistema Operacional: Red Hat 5.8 Enterprise 64B
Oracle Enterprise 11.2.0.3

 
O que vc's sugerem para alteração\ajuste nos paramentros de SGA, PGA, etc?

SQL>  show parameter target

NAME TYPEVALUE
 --- --
archive_lag_target   integer 0
db_flashback_retention_targetinteger 1440
fast_start_io_target integer 0
fast_start_mttr_target   integer 0
memory_max_targetbig integer 0
memory_targetbig integer 0
parallel_servers_target  in