Con esta breve publicación gustaríame disipar un malentendido relacionado coa análise das bases de datos AWR que se executan en Oracle Exadata. Durante case 10 anos, teño que enfrontarme constantemente á pregunta: cal é a contribución de Exadata Software á produtividade? Ou usando palabras recentemente acuñadas: como de "experto" é o traballo dunha determinada base de datos?
A miúdo esta pregunta correcta, na miña opinión, responde incorrectamente con referencia ás estatísticas de AWR. Presenta o método de espera do sistema, que trata o tempo de resposta como a suma do tempo de funcionamento dos procesadores (CPU de base de datos) e o tempo de espera de varias clases.
Coa chegada de Exadata, nas estatísticas de AWR apareceron expectativas específicas do sistema relacionadas co funcionamento do software Exadata. Como regra xeral, os nomes destas esperas comezan coa palabra "célula" (o servidor de Exadata Storage chámase cela), das cales as máis comúns son as esperas cos nomes autoexplicativos "escaneo de táboa intelixente de cela", "multiblock de celas". lectura física" e "lectura física de bloque único da cela".
Na maioría dos casos, a proporción de tales esperas de Exadata no tempo de resposta total é pequena e, polo tanto, nin sequera entran na sección Top10 Events foreground by Total Wait Time (neste caso, cómpre buscalas na Foreground Wait). sección de eventos). Con moita dificultade atopamos un exemplo de AWR diario dos nosos clientes, no que as expectativas de Exadata estaban incluídas na sección Top10 e en total ascendían a preto do 5%:
evento
Agarda
Tempo de espera total (s)
Agarda media
% DB tempo
Espera clase
CPU de base de datos
115.2K
70.4
SQL*Net máis datos de dblink
670,196
5471.5
8.16ms
3.3
Rede
lectura física de bloque único celular
5,661,452
3827.6
676.07us
2.3
E/S de usuario
Sincronizar reequilibrio ASM
4,350,012
3481.3
800.30us
2.1
Outra
lectura física multibloque celular
759,885
2252
2.96ms
1.4
E/S de usuario
ruta directa de lectura
374,368
1811.3
4.84ms
1.1
E/S de usuario
Mensaxe SQL*Net de dblink
7,983
1725
216.08ms
1.1
Rede
dixitalización de táboa intelixente de células
1,007,520
1260.7
1.25ms
0.8
E/S de usuario
ruta directa lectura temp
520,211
808.4
1.55ms
0.5
E/S de usuario
enq: TM - contención
652
795.8
1220.55ms
0.5
aplicación
As seguintes conclusións adoitan extraerse de tales estatísticas de AWR:
1. A contribución da maxia de Exadata ao rendemento da base de datos non é alta: non supera o 5% e a base de datos "exadatiza" mal.
2. Se tal base de datos se transfire de Exadata á clásica arquitectura "servidor + matriz", entón o rendemento non cambiará moito. Porque aínda que esta matriz resulte ser tres veces máis lenta que o sistema de almacenamento Exadata (o que dificilmente é posible para as matrices All Flash modernas), multiplicando o 5% por tres, obtemos un aumento na proporción de esperas de E/S ata o 15% - ¡A base de datos sobrevivirá a isto!
Estas dúas conclusións son inexactas, ademais, distorsionan a comprensión da idea detrás de Exadata Software. Exadata non só ofrece E/S rápida, funciona de forma fundamentalmente diferente en comparación coa arquitectura clásica de servidor + matriz. Se o funcionamento da base de datos está verdadeiramente "exadaptado", entón a lóxica SQL transfírese ao sistema de almacenamento. Os servidores de almacenamento, grazas a unha serie de mecanismos especiais (principalmente índices de almacenamento Exadata, pero non só), atopan eles mesmos os datos necesarios e envían a base de datos aos servidores. Fano de forma bastante eficiente, polo que a proporción de esperas típicas de Exadata no tempo de resposta total é pequena.
Como cambiará esta participación fóra de Exadata? Como afectará isto ao rendemento da base de datos no seu conxunto? As probas responderán mellor a estas preguntas. Por exemplo, a espera dunha "exploración da táboa intelixente de células" fóra de Exadata pode converterse nunha exploración completa de táboa tan pesada que a E/S ocupa todo o tempo de resposta e o rendemento se degrada drasticamente. Por iso é incorrecto, ao analizar AWR, considerar a porcentaxe total das expectativas de Exadata como a contribución da súa maxia ao rendemento, e máis aínda utilizar esta porcentaxe para predicir o rendemento fóra de Exadata. Para comprender o "exacto" do traballo da base de datos, cómpre estudar as estatísticas de AWR da sección "Estadísticas de actividade de instancias" (hai moitas estatísticas con nomes autoexplicativos) e comparalas entre elas.
E para entender como se sentirá unha base de datos fóra de Exadata, o mellor é facer un clon de base de datos a partir dunha copia de seguridade na arquitectura de destino e analizar o rendemento deste clon baixo carga. Os propietarios de Exadata, por regra xeral, teñen esta oportunidade.
autor: Alexey Struchenko, xefe do departamento de bases de datos de Jet Infosystems
Fonte: www.habr.com