Menu de navegação

[Gustavo L. P. GomesParticipante]

Boa tarde Pessoal,

Estou com um problema de db file sequential read muito alto, as estatísticas estão atualizadas alguém tem alguma sugestão do que pode ser?

Executei a select abaixo do Ricardo Portilho:

SET PAGESIZE 1000;
SET LINESIZE 210;
COL EVENT FORMAT A80;

CREATE TABLE PRE_SYSTEM_EVENT AS SELECT * FROM V$SYSTEM_EVENT;
EXECUTE DBMS_LOCK.SLEEP(600);
CREATE TABLE POS_SYSTEM_EVENT AS SELECT * FROM V$SYSTEM_EVENT;

SELECT A.EVENT, A.TIME_WAITED, B.TIME_WAITED, (B.TIME_WAITED-A.TIME_WAITED) DIFF
FROM PRE_SYSTEM_EVENT A, POS_SYSTEM_EVENT B
WHERE A.EVENT = B.EVENT
AND A.TIME_WAITED IS NOT NULL
AND ((B.TIME_WAITED-A.TIME_WAITED) > 0)
AND A.WAIT_CLASS != ‘Idle’
ORDER BY DIFF;


EVENT TIME_WAITED TIME_WAITED DIFF
-------------------------------------------------------------------------------- ----------- -------
latch: object queue header operation 5823 5824 1
latch: cache buffers lru chain 903 904 1
log file single write 38 41 3
enq: TX - index contention 503 522 19
LGWR wait for redo copy 506 552 46
SQL*Net more data from client 1159 1269 110
latch: messages 736 875 139
log file switch completion 5072 5325 253
latch: library cache pin 1201 1499 298
Streams AQ: qmn coordinator waiting for slave to start 1954 2442 488
enq: SQ - contention 249290 249790 500
Log archive I/O 2153 2721 568
db file parallel read 24228 24810 582
library cache pin 1842075 1842678 603
log file sequential read 22213 23817 1604
control file sequential read 9331 11417 2086
SQL*Net message to client 4264 6514 2250
latch: row cache objects 84296 86707 2411
control file parallel write 28686 32756 4070
os thread startup 16516 21757 5241
latch: redo writing 5523 12233 6710
latch: In memory undo latch 66 7346 7280
latch: session allocation 484608 493750 9142
log file parallel write 112031 125047 13016
SQL*Net more data to client 90408 103605 13197
SQL*Net break/reset to client 9232 37142 27910
log file sync 682523 736756 54233
db file scattered read 342684 427093 84409
latch: redo allocation 3227 111991 108764
buffer busy waits 3417 175153 171736
latch: shared pool 206791 435731 228940
latch: cache buffers chains 309678 585813 276135
db file sequential read 2120902 2426317 305415
latch free 1182600 1764076 581476
latch: library cache lock 94977 842143 747166
latch: library cache 767366 2327280 1559914

36 linhas selecionadas.


[rmanParticipante]

@gustavolpgomes

db file sequential read é o evento de espera gerado pelo FULL TABLE SCAN. Identifique o SQL e analise uma possível criação de índice, ou ainda, dependendo da situação a inclusão de um filtro também resolve, isso vai te levar novamente a uma possível criação de índice.

[Fábio PradoParticipante]

Pessoal,

db file sequential read é o tempo de espera por leituras em índices e não FTS!

Nem sempre um valor alto para este evento (assim como muitos outros) significa um problema. Descubra, por exemplo, se no período de 1 hora este evento foi maior que 20ms. Se não foi, nem se preocupe! O AWR é uma ótima ferramenta para vc analisar isso!

[]s

[rmanParticipante]

@fbifabio

Realmente db file sequential read é o tempo de espera por leituras em índices. Me confundi com o db file scattered read, esse sim é FULL TABLE SCAN.

db file sequential read pode ser causado por um hint que force a utilização de índice.

[Gustavo L. P. GomesParticipante]

Pessoal neste caso será que se eu separar os índices em outro grupo de discos vou ter uma melhora na performance?

[Gustavo L. P. GomesParticipante]

Dados do servidor:

Processador: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz –> 24 núcleos
Memória: 16 GB
4 discos em RAID 1 + 0

Arquivo /etc/sysctl.conf:

Kernel sysctl configuration file for Red Hat Linux

#

For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and

sysctl.conf(5) for more details.

Controls IP packet forwarding

net.ipv4.ip_forward = 0

Controls source route verification

net.ipv4.conf.default.rp_filter = 1

Do not accept source routing

net.ipv4.conf.default.accept_source_route = 0

Controls the System Request debugging functionality of the kernel

kernel.sysrq = 0

Controls whether core dumps will append the PID to the core filename

Useful for debugging multi-threaded applications

kernel.core_uses_pid = 1

Controls the use of TCP syncookies

net.ipv4.tcp_syncookies = 1

Controls the maximum size of a message, in bytes

kernel.msgmnb = 65536

Controls the default maxmimum size of a mesage queue

kernel.msgmax = 65536

Controls the maximum shared segment size, in bytes

#kernel.shmmax = 68719476736
kernel.shmmax = 8589934592

Controls the maximum number of shared memory segments, in pages

#kernel.shmall = 4294967296
kernel.shmall = 4194304

Inicio Parametros Oracle

kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144

Fim parametros Oracle

Arquivo Init.ora:


cliente.__db_cache_size=5200936960
cliente.__java_pool_size=16777216
cliente.__large_pool_size=16777216
cliente.__shared_pool_size=1023410176
cliente.__streams_pool_size=0
.audit_file_dest='/u01/app/oracle/admin/cliente/adump'
*.background_dump_dest='/u01/app/oracle/admin/cliente/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/u01/app/oracle/cliente/control/control01.ctl','/u01/app/oracle/cliente/control/control02.ctl','/u01/app/oracle/cliente/control/control03.ctl'
*.core_dump_dest='/u01/app/oracle/admin/cliente/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='cliente'
#.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
#*.db_recovery_file_dest_size=2147483648
*.log_archive_dest=/u01/app/oracle/cliente/archives/
*.log_archive_format=%s_%t_%r_.arc
*.dispatchers='(PROTOCOL=TCP) (SERVICE=clienteXDB)'
*.job_queue_processes=10
*.nls_language='BRAZILIAN PORTUGUESE'
*.nls_territory='BRAZIL'
*.open_cursors=60000
*.pga_aggregate_target=2089811968
*.processes=3000
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=2147483648
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/cliente/udump'
*.utl_file_dir='/home/oracle/spool/'


Alguém tem alguma sugestão do que pode ser alterado para melhorar o desempenho?
Abraços!!!

[Fábio PradoParticipante]

Separar os índices em outro grupo de discos pode melhorar a performance se estes novos discos tiverem algum dos seguintes requisitos:

• são mais rápidos
• tem menos concorrência de leitura/gravação
• são gerenciados por outra controladora de discos

Outras coisas que podem ser feitas para reduzi-lo:
– Otimize instruções SQL;
– Configure apropriadamente a SGA (considere aumentar a buffer cache);
– Descubra quais são os indices que mais causam este wait event e verifique eles foram criados com o tipo correto e se não precisam de rebuild ou shrink
– Utilize Flash Cache p/ armazenar os indices que tem mais wait events;
– Considere o uso de tabelas clusterizadas ou particionadas

[]s

[Gustavo L. P. GomesParticipante]

Pessoal, muito obrigado pelas dicas, o problema foi solucionado em partes. Executei os comandos abaixo:

• ALTER TABLE … ENABLE ROW MOVEMENT;
• ALTER TABLE … SHRINK SPACE CASCADE;
• ALTER TABLE … DISABLE ROW MOVEMENT;

O desempenho melhorou muito após os comando, @fbifabio vou estudar para utilizar flash cache para armazenar os índices!
Obrigado a todos!!

[Autor]

Posts