Pular para o conteúdo
  • Este tópico contém 7 respostas, 3 vozes e foi atualizado pela última vez 10 anos, 6 meses atrás por Avatar de Gustavo L. P. GomesGustavo L. P. Gomes.
Visualizando 8 posts - 1 até 8 (de 8 do total)
  • Autor
    Posts
  • #105771
    Avatar de Gustavo L. P. GomesGustavo L. P. Gomes
    Participante

      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.

      #105772
      Avatar de rmanrman
      Participante

        @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.

        #105777
        Avatar de Fábio PradoFábio Prado
        Participante

          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

          #105778
          Avatar de rmanrman
          Participante

            @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.

            #105794
            Avatar de Gustavo L. P. GomesGustavo L. P. Gomes
            Participante

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

              #105795
              Avatar de Gustavo L. P. GomesGustavo L. P. Gomes
              Participante

                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!!!

                #105799
                Avatar de Fábio PradoFábio Prado
                Participante

                  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

                  #105809
                  Avatar de Gustavo L. P. GomesGustavo L. P. Gomes
                  Participante

                    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!!

                  Visualizando 8 posts - 1 até 8 (de 8 do total)
                  • Você deve fazer login para responder a este tópico.
                  plugins premium WordPress