Investigar o SCN taxa de crescimento intrínseca

Written by on in Articles

Publicado em: 10 de julho de 2018 Autor: Bastiaan Bak Categoria: desenvolvimento e operações

há Um tempo atrás, tivemos um aviso sobre a intrínseca de crescimento do SCN (system change number) na nossa Oracle 12.2 alerta de banco de dados de arquivo. Esta situação ocorreu várias vezes dentro de algumas semanas.

“aviso: a taxa de crescimento intrínseca do SCN tem sido consistentemente
maior do que o padrão do sistema 16384 por segundo. nos últimos 60 minutos.
a taxa de crescimento intrínseca atual do SCN é 25867 por segundo., zas 200fffff!
o valor SCN atual é 46747726691, o valor SCN Compat é 1″

minha reação inicial foi que SCNs estão relacionados a commits, portanto, a carga no banco de dados era muito alta ou a lógica do aplicativo deveria ser alterada. Outra possibilidade era que um commit fosse feito após cada atualização, em vez de usar commits em lote.

acabou sendo um pouco mais complicado do que eu esperava. Onde você olha quando deseja encontrar a relação entre SCNs e commits? E quão sério é esse aviso de qualquer maneira? Este blog vai ser sobre as várias maneiras que eu investiguei este problema e identificou o impacto potencial.

Oracle Support notes

o primeiro lugar para procurar informações sobre avisos no arquivo de alerta é o site de Suporte do Oracle. Encontrei várias notas relacionadas:

  • ORA – 19706 e mensagens de log de alerta relacionadas(Doc ID 1393360.1)
    esta nota sugere que a mensagem real é específica para a versão 12.2 do banco de dados, mas em versões mais antigas podemos ter avisos semelhantes, como ” aviso: o espaço livre do SCN para este banco de dados é de apenas NN dias!”
    se você encontrar uma mensagem de log de alerta como qualquer uma dessas entradas, é aconselhável seguir as instruções no ID 1388639.1 e registrar uma solicitação de serviço com o Suporte Oracle.
    evidências a serem coletadas ao relatar problemas de “alta taxa de SCN” ao Suporte Oracle (Doc ID 1388639.1)
  • esta nota fornece informações sobre quais informações você deve fornecer ao registrar uma solicitação de serviço.
  • System Change Number (SCN), Headroom, Security and Patch Information (Doc ID 1376995.1)
    esta nota fornece mais informações sobre o uso do SCN. O número de alteração do sistema (SCN) é um carimbo de data / hora interno lógico usado pelo Banco de Dados Oracle. Os SCNs ordenam eventos que ocorrem dentro do banco de dados. O banco de dados usa SCNs para consultar e rastrear alterações. Quando uma transação é confirmada, o banco de dados registra um SCN para essa confirmação.Há um limite superior para quantos SCNs um banco de Dados Oracle pode usar. O limite é atualmente 281 trilhões (2^48) valores SCN.
    dado que há um limite superior, é importante que qualquer banco de Dados Oracle não fique sem SCNs disponíveis.
    a nota também explica quando o aviso é levantado. O banco de Dados Oracle calcula um limite” não exceder ” para o número de SCNs que um banco de dados pode usar atualmente, com base no número de segundos desde 1988 multiplicado por 16384. Isso garante que os bancos de Dados Oracle racionem SCNs ao longo do tempo.

quão sério é esse aviso?

o aviso é aumentado a uma taxa de 2^14 = 16384 SCNs por segundo nos últimos 60 minutos.
o SCN máximo é 2^48 = 281.474.976.710.656.

a uma taxa de 16348 SCNs por segundo, teremos 2^(48-14) segundos, ou 544 anos para atingir esse máximo. Isso deve ser suficiente em uma situação normal, mas o limite superior de 2^48 é apenas o valor absoluto máximo que o banco de dados pode armazenar.
o limite também está relacionado ao número de segundos desde 1988. O limite de 2^48 é o máximo no ano 2532 (1988+544). Mas em 2018 o máximo é (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

o aviso não deve ser ignorado. Quando você atingir o limite, obterá erros ora-600, mas quando atingir o limite superior absoluto SCN, o banco de dados simplesmente deixará de funcionar.

a boa notícia é que, em nossa situação, o aviso dizia que a taxa de crescimento do SCN era de 25867 por segundo naquela hora específica, então naquela hora chegamos um pouco mais perto (25867-16384=9483) do limite. Não chegamos perto do limite a cada hora; a taxa de crescimento normal é inferior a 16384.

suporte Oracle

ligamos para o Oracle Support e eles nos disseram que o Oracle Development está atualmente trabalhando nesse problema.
o Oracle Support confirmou que o headroom do SCN parece bom. Com base no relatório AWR, o Oracle Support notou um grande número de commits e sugeriu verificar com a equipe do aplicativo para commit, aumentando o tamanho da transação.

investigação com AWR

o aviso no arquivo de alerta nos disse que a taxa de crescimento intrínseca do SCN tem sido consistentemente maior do que o padrão do sistema: 16384 por segundo nos últimos 60 minutos. Se estivermos olhando para um período de uma hora, um relatório AWR pode ser um bom lugar para começar. Temos AWR configurado para fazer instantâneos a cada hora.

no relatório AWR, notei que o número de commits de usuário era 210 por segundo. Sim, isso é um monte de commits, mas não é tão diferente da carga normal deste banco de dados. E se um commit está relacionado a um SCN, também é muito menor que 16384 por segundo.

o relatório AWR também continha um achado ADDM: Waits no evento “log File sync” durante a execução de operações de COMMIT e ROLLBACK estavam consumindo tempo significativo de banco de dados. Investigue a lógica do aplicativo para possível redução no número de operações de confirmação, aumentando o tamanho das transações.
essa redução dos commits na descoberta de ADDM também foi sugerida pelo Oracle Support. Do meu ponto de vista, não foi tão alto.

período de tempo mais curto

porque o AWR não estava me ajudando a encontrar a causa, eu precisava investigar um período de tempo mais curto. Eu queria saber um prazo mais específico para que eu pudesse criar um relatório ASH. O padrão para ASH é de 15 minutos.Portanto, o próximo desafio foi encontrar o período de 15 minutos em que a taxa de crescimento do SCN foi a mais alta.
Doc ID 1388639.1 sugerido para consultar v $ archived_log. Essa visualização tem informações sobre todos os switches de log no banco de dados, incluindo um carimbo de data / hora e o SCN. Embora você possa mapear carimbos de data / hora para SCNs, não é realmente melhor do que o relatório AWR. Ainda estamos presos a carimbos de data / hora aleatórios; neste caso, o carimbo de data / hora do logswitch.

usando a função timestamp_to_scn

uma maneira melhor é usar a função timestamp_to_scn. Esta função retorna um SCN com base em um carimbo de data / hora, como o carimbo de data / hora atual:

     
  1. SQL> selecione timestamp_to_scn (sysdate) do dual ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN(SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

O próximo passo foi fazer uma lista de carimbos de data / hora, juntamente com a correspondência de SCN e o correspondente SCN limite superior, baseado no número de segundos desde 1988 multiplicado por 16.384.

isso mostra os carimbos de data / hora e SCNs para o último dia:

     
  1.  SELECT sysdate - (rownum/24) datetimestamp
    2.  
  2.  , timestamp_to_scn(sysdate - (rownum/24)) SCN
    3.  
  3.  , ((sysdate - (rownum/24)) - to_date('01-01-1988','DD-MM-YYYY' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  dupla
    6.  
  6.  CONECTAR rownum <= 24 
    7.  
  7. /
    8.  
     
  1. DATETIMESTAMP SCN UPPER_LMT
    2.  
  2.  ------------------- -------------------- -------------------- 
    3.  
  3. 09-07-2018-13:23:39 95423916508 15780233527296 
    4.  
  4. 09-07-2018-12:23:39 95380086165 15780174544896 
    5.  
  5. 09-07-2018-11:23:39 95338871931 15780115562496 
    6.  
  6. 09-07-2018-10:23:39 95303437600 15780056580096 
    7.  
  7. 09-07-2018-09:23:39 95265573942 15779997597696 
    8.  
  8. 09-07-2018-08:23:39 95226645452 15779938615296 
    9.  
  9. 09-07-2018-07:23:39 95186822906 15779879632896 
    10.  
  10. 09-07-2018-06:23:39 95147382509 15779820650496 
    11.  
  11. 09-07-2018-05:23:39 95115474008 15779761668096 
    12.  
  12. 09-07-2018-04:23:39 95079712219 15779702685696 
    13.  
  13. 09-07-2018-03:23:39 95041469231 15779643703296 
    14.  
  14. 09-07-2018-02:23:39 95006499794 15779584720896 
    15.  
  15. 09-07-2018-01:23:39 94975060529 15779525738496 
    16.  
  16. 09-07-2018-00:23:39 94945771055 15779466756096 
    17.  
  17. 08-07-2018-23:23:39 94907451372 15779407773696 
    18.  
  18. 08-07-2018-22:23:39 94875158341 15779348791296 
    19.  
  19. 08-07-2018-21:23:39 94838756696 15779289808896 
    20.  
  20. 08-07-2018-20:23:39 94800190958 15779230826496 
    21.  
  21. 08-07-2018-19:23:39 94757984611 15779171844096 
    22.  
  22. 08-07-2018-18:23:39 94724548846 15779112861696 
    23.  
  23. 08-07-2018-17:23:39 94685506947 15779053879296 
    24.  
  24. 08-07-2018-16:23:39 94646644945 15778994896896 
    25.  
  25. 08-07-2018-15:23:39 94605003069 15778935914496 
    26.  
  26. 08-07-2018-14:23:39 94572205685 15778876932096 
    27.  
  27.  
    28.  
  28.  24 linhas selecionadas. 
    29.

o SCN atual é de cerca de 0,57% do limite superior atual.

encontrar a taxa de SCN superior

com base nessa ideia, criei uma consulta que me dá o período de 15 minutos com maior crescimento em SCNs nos últimos 3 dias.

a cada minuto um novo período de tempo começa, e porque temos 1440 minutos em um dia, temos 4320 prazos para investigar. Para cada um deles, temos que calcular o crescimento do SCN dentro desse prazo de 15 minutos.

queremos apenas mostrar os melhores resultados, neste caso apenas os prazos com uma taxa de mais de 14000 por segundo.

     
  1.  ALTER SESSION SET nls_date_format= 'MM / dd / YY HH24: MI' ;
    2.  
  2.  
    3.  
  3.  COM datelist COMO 
    4.  
  4.  ( SELECT sysdate - (rownum/1440) - (15/1440) hora de início -- intervalo de 15 minutos 
    5.  
  5.  , sysdate - (rownum/1440) endtime
    6.  
  6.  dupla
    7.  
  7.  CONECTAR rownum <= (3*1440) -- 3 dias da história 
    8.  
  8. )
    9.  
  9.  SELECIONE a hora de início
    10.  
  10.  , endtime
    11.  
  11.  , timestamp_to_scn(endtime) - timestamp_to_scn(hora de início) scngrowth
    12.  
  12.  , round((timestamp_to_scn(endtime) - timestamp_to_scn(starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime )))) scnrate
    14.  
  14.  a PARTIR de datelist
    15.  
  15.  ONDE round((timestamp_to_scn(endtime) - timestamp_to_scn(starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  ORDEM POR 4 DESC 
    18.  
  18. /
    19.  
     
  1. hora de ínicio, hora de TÉRMINO SCNGROWTH SCNRATE
    2.  
  2. -------------- -------------- -------------------- --------------------
    3.  
  3. 07/06/18 18:09 07/06/18 18:24 12761928 14180 
    4.  
  4. 07/07/18 05:20 07/07/18 05:35 12742537 14158 
    5.  
  5. 07/09/18 13:59 07/09/18 14:14 12705077 14117 
    6.  
  6. 07/09/18 12:57 07/09/18 13:12 12672507 14081 
    7.  
  7. 07/09/18 07:06 07/09/18 07:21 12654287 14060 
    8.

Então, agora temos encontrado o (por vezes, sobreposição) de 15 minutos de tempo de quadros com maior SCN taxa (SCN crescimento por segundo) para os 3 últimos dias. E mesmo nesses prazos, a taxa SCN ainda está abaixo de 16384. Nenhum aviso no arquivo de alerta esta semana….

executando o relatório ASH

o formato de data que usei na consulta acima é o mesmo usado pelo relatório ASH, para que você possa simplesmente copiar/colar a hora de início. Durante a duração, inserimos 15 minutos.

     
  1. como baixar e instalar Minecraft.sql
    2.  
  2.  
    3.  
  3. ASH Exemplos neste Carga de trabalho do Repositório de esquema
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. mais antigas CINZAS de exemplo disponível em: 01-Jul-18 00:00:01 
    7.  
  7. Últimas CINZAS amostra disponível: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. Especificar o período de tempo PARA gerar o relatório de CINZAS
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. Introduza o TEMPO inicial PARA o relatório de:
    13.  
  13.  
    14.  
  14. -- Válido formatos de entrada:
    15.  
  15. -- Para especificar começo tempo absoluto:
    16.  
  16. -- ] HH24:MI
    17.  
  17. -- Exemplos: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- Para especificar relativa começar a tempo: (iniciar com o sinal '-' )
    22.  
  22. -- -MI
    23.  
  23. -- Exemplos: -1:15 (SYSDATE - 1 hora e 15 Minutos)
    24.  
  24. -- -25 (SYSDATE - 25 Minutos)
    25.  
  25.  
    26.  
  26. Padrões PARA -15 minutos
    27.  
  27. Introduza um VALOR PARA begin_time: 07/06/18 18:09
    28.  
  28. Relatório de COMEÇAR de TEMPO especificado: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. Inserir a duração EM minutos, a partir DO início do HORÁRIO de:
    31.  
  31. Padrões PARA SYSDATE - begin_time
    32.  
  32. Pressione Enter PARA analisar até o TEMPO ATUAL 
    33.  
  33. Introduza o VALOR PARA a duração: 15 
    34.  
  34. Relatório de duração especificado: 15 
    35.  
  35.  
    36.  
  36.  USANDO 06-Jul-18 18:09:00, CONFORME relatório de COMEÇAR HORA 
    37.  
  37.  USANDO 06-Jul-18 18:24:00 COMO relatório FINAL TEMPO 
    38.  
  38.  
    39.  
  39. Especificar o Nome do Relatório
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. O PADRÃO de nome de ficheiro do relatório É ashrpt_1_0706_1824.galeria. Para usar este nome, 
    42.  
  42. pressione < return > para continuar, caso contrário, insira uma alternativa. 
    43.  
  43. insira o valor para report_name:
    44.  
  44.  
    45.  
  45.  USANDO o nome de relatório ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. Resumo DE TODAS as entradas do USUÁRIO 
    48.  
  48. -------------------------
    49.  
  49. Formato : HTML
    50.  
  50. DB Identificação : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  HORA inicial : 06-Jul-18 18:09:00
    53.  
  53.  HORA de FIM : 06-Jul-18 18:24:00
    54.  
  54. largura da Ranhura : PADRÃO 
    55.  
  55. Relatório de metas : 0 
    56.  
  56. nome do Relatório : ashrpt_1_0706_1824.html
    57.

Encontrar SCN de RMA

O RMA relatório não mostra-nos o máximo de informações sobre o atual SCN, mas tem algumas informações sobre a taxa de crescimento, se você sabe onde encontrá-lo.

em “Instance Activity Stats” você pode encontrar o número de “chamadas para kcmgas”. Na documentação do Oracle, isso é descrito como o “número de chamadas para kcmgas de rotina para obter um novo SCN”.

o valor dessas chamadas por segundo no relatório AWR é muito próximo da taxa SCN calculada com a função timestamp_to_scn.

V $ sestat view

o número de” chamadas para kcmgas ” usadas para criar um novo SCN também pode ser encontrado nas visualizações V$SESTAT e V$SYSSTAT.

podemos usar V $ SESTAT para encontrar as sessões que causam uma alta taxa de SCN. Também podemos testar o impacto no número SCN de ações específicas.

por exemplo, quando faço um select em uma tabela grande que também está em uso por outras sessões, minha sessão fará outras 7 chamadas para kcmgas. Portanto, minha consulta causará um SCN mais alto. Isso é causado pela consistência de leitura do banco de dados, que também usa um SCN.

     
  1. SQL> CONECTAR <usuário>/<pass>@<serviço> 
    2.  
  2. Ligado. 
    3.  
  3. SQL> selecione ses.valor
    4.  
  4.  v$sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  ONDE stat.estatística# = ses.estatística#
    7.  
  7.  e ses.sid IN (selecionar sid a partir de V $ mystat) 
    8.  
  8.  e stat.nome = 'chamadas para kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  VALOR 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> SELECT COUNT(*) FROM mybigtable ;
    16.  
  16.  
    17.  
  17.  CONTAGEM(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> SELECIONE o ses.valor
    22.  
  22.  v$sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  ONDE stat.estatística# = ses.estatística#
    25.  
  25.  e ses.sid IN (selecionar sid a partir de V $ mystat) 
    26.  
  26.  e stat.nome = 'chamadas para kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  VALOR 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

Comparando o SCN e cometer taxa de

Com V$SESSTAT nós podemos consultar as estatísticas para todas as sessões, atualmente conectado ao banco de dados. Desta forma, podemos encontrar sessões responsáveis por uma alta taxa de SCN. Podemos comparar isso com a taxa de commit para essa sessão.

os resultados da consulta abaixo nos mostraram que em nosso banco de dados a alta taxa de SCN foi causada principalmente por processos em segundo plano. Para a maioria das sessões de usuário, há uma relação entre uma alta taxa de SCN e uma alta taxa de commit, para sessões em segundo plano, a taxa de commit está sempre vazia.

     
  1.  selecione ses.sid
    2.  
  2.  , decode (ses.nome de usuário ,NULL,'plano de fundo','usuário' ) session_type
    3.  
  3.  , (sysdate - logon_time) * 24 * 60 * 60 connect_seconds
    4.  
  4.  , sstat1.valor SCN#
    5.  
  5.  , sstat2.value COMMIT#
    6.  
  6.  , rodada (sstat1.valor / ((sysdate - logon_time ) * 24 * 60 * 60),2) scn_rate
    7.  
  7.  , round(sstat2.valor / ((sysdate - logon_time ) * 24 * 60 * 60),2) commit_rate
    8.  
  8.  v$sesstat sstat1
    9.  
  9.  , v$sesstat sstat2
    10.  
  10.  , v$statname sn1
    11.  
  11.  , v$statname sn2
    12.  
  12.  , v$session ses
    13.  
  13.  ONDE sstat1.estatística # = sn1.estatística#
    14.  
  14.  E sstat2.estatística # = sn2.estatística#
    15.  
  15.  e sn1.nome = 'chamadas para kcmgas' 
    16.  
  16.  E sn2.nome = 'usuário compromete-se' 
    17.  
  17.  E ses.sid = sstat1.sid
    18.  
  18.  e ses.sid = sstat2.sid
    19.  
  19.  ORDEM POR 6 DESC 
    20.  
  20. /
    21.  
  21.  
    22.  
  22.  SID SESSION_TY CONNECT_SECONDS SCN# COMETER# SCN_RATE COMMIT_RATE
    23.  
  23. ---------- ---------- --------------- ---------- ---------- ---------- -----------
    24.  
  24.  8478 fundo 459572 214506344 0 466.75 0 
    25.  
  25.  7551 fundo 452395 209729934 0 463.6 0 
    26.  
  26.  3776 fundo 290389 133863489 0 460.98 0 
    27.  
  27.  8496 fundo 121201 55685740 0 459.45 0 
    28.  
  28.  8729 fundo 286773 128180386 0 446.98 0 
    29.  
  29.  12009 fundo 290392 128867329 0 443.77 0 
    30.  
  30.  13173 fundo 196775 87268032 0 443.49 0 
    31.  
  31.  12004 fundo 103166 45681480 0 442.8 0 
    32.  
  32.  8735 fundo 275980 121563094 0 440.48 0 
    33.  
  33.  3096 fundo 430810 185436599 0 430.44 0 
    34.  
  34.  8027 fundo 95990 40912187 0 426.21 0 
    35.  
  35.  7529 fundo 193218 81367643 0 421.12 0 
    36.  
  36.  2370 fundo 527978 219521415 0 415.78 0 
    37.  
  37.  14604 fundo 283216 117052382 0 413.3 0 
    38.  
  38.  14132 fundo 113965 46586388 0 408.78 0 
    39.  
  39.  7552 fundo 294009 119775077 0 407.39 0 
    40.  
  40.  13172 fundo 182423 73865595 0 404.91 0 
    41.  
  41.  14592 fundo 74414 29767705 0 400.03 0 
    42.  
  42.  3802 fundo 268804 107486102 0 399.87 0 
    43.  
  43.  9910 fundo 117582 46596720 0 396.29 0 
    44.  
  44.  12021 fundo 49182 19321676 0 392.86 0 
    45.  
  45.  974 fundo 160816 59996495 0 373.08 0 
    46.  
  46.  12723 fundo 74450 25455559 0 341.91 0 
    47.  
  47.  3310 fundo 193215 65915175 0 341.15 0 
    48.  
  48.  12963 fundo 49179 15687084 0 318.98 0 
    49.  
  49.  6111 fundo 3584090 1031139557 0 287.7 0 
    50.  
  50.  6829 UTILIZADOR 303 1267 1123 4.18 3.71 
    51.  
  51.  9665 UTILIZADOR 904 1845 1691 2.04 1.87 
    52.  
  52.  8022 UTILIZADOR 898 1677 1520 1.87 1.69 
    53.  
  53.  3323 UTILIZADOR 898 1406 1260 1.57 1.4 
    54.  
  54.  2839 UTILIZADOR 7503 10822 9813 1.44 1.31 
    55.  
  55.  11060 UTILIZADOR 3892 5334 4781 1.37 1.23 
    56.  
  56.  13184 UTILIZADOR 1765 2359 2038 1.34 1.15 
    57.  
  57.  9199 USUÁRIO 898 1135 935 1.26 1.04 
    58.  
  58.  2130 UTILIZADOR 8105 9548 8518 1.18 1.05 
    59.  
  59.  11525 UTILIZADOR 898 1054 944 1.17 1.05 
    60.  
  60.  6130 UTILIZADOR 3895 4453 4199 1.14 1.08 
    61.  
  61.  8012 UTILIZADOR 7503 8576 7774 1.14 1.04 
    62.  
  62.  4497 USUÁRIO 898 962 882 1.07 .98
    63.  
  63.  5201 usuário 7220 7551 6226 1.05 .86
    64.  
  64.  11317 USUÁRIO 12906 13371 11997 1.04 .93
    65.  
  65.  
    66.  
  66.  
    67.  
  67.  1979 LINHAS selecionadas. 
    68.

Conclusão

Estar ciente de que existem limites para o SCN, então, quando você encontrar advertências no arquivo de alerta, você precisa investigar o problema. Se você encontrar um problema, deve trabalhar com o Oracle Support. Ao enviar informações, eles podem verificar se há espaço suficiente entre o SCN atual e o máximo.

os problemas podem ser causados por um bug, como 12371955: o Hot Backup pode causar aumento da taxa de crescimento do SCN, levando a erros ORA-600 (Doc ID 12371955.8).

se você quiser encontrar o momento exato, há um alto crescimento de SCNs, você precisa converter carimbos de data / hora em SCNs. Você obtém os melhores resultados usando as funções SCN_TO_TIMESTAMP e TIMESTAMP_TO_SCN.

uma alta taxa de commit está sempre relacionada aos processos do usuário, mas os SCNs também estão relacionados aos processos em segundo plano. Mesmo sessões que não se comprometem podem ter um impacto no SCN.

Bastiaan Bak

Sobre o autor Bastiaan Bak

DBA com mais de 15 anos de experiência. Experiência em vários ramos, com vários módulos. Comer: Banco de dados Oracle, Oracle RAC, Oracle EBS e PL / SQL.

Mais Postagens de Bastiaan Bak

Deixe uma resposta

O seu endereço de email não será publicado.