![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nCon esta breve publicaci\u00f3n, me gustar\u00eda aclarar un malentendido relacionado con el an\u00e1lisis de AWR de bases de datos que funcionan en Oracle Exadata. Durante casi 10 a\u00f1os, he enfrentado constantemente la pregunta: \u00bfcu\u00e1l es la contribuci\u00f3n del software Exadata al rendimiento? O usando t\u00e9rminos reci\u00e9n acu\u00f1ados: \u00bfcu\u00e1nto \"exadatiza\" el funcionamiento de una base de datos en particular?<\/p>\n
<\/p>\n
A menudo, se da una respuesta incorrecta a esta pregunta, en mi opini\u00f3n, refiri\u00e9ndose a la estad\u00edstica de AWR. Esta presenta un m\u00e9todo de esperas del sistema que interpreta el tiempo de respuesta como la suma del tiempo de trabajo de los procesadores (DB CPU) y el tiempo de espera de diversas clases.<\/p>\n
Con la aparici\u00f3n de Exadata, en la estad\u00edstica de AWR se incluyeron esperas del sistema espec\u00edficas relacionadas con el funcionamiento del software Exadata. Generalmente, los nombres de estas esperas comienzan con la palabra \u201ccell\u201d (la celda se refiere al servidor de almacenamiento Exadata), entre las cuales las m\u00e1s comunes son las esperas de nombre sugestivo como \u201ccell smart table scan\u201d, \u201ccell multiblock physical read\u201d y \u201ccell single block physical read\u201d.<\/p>\n
En la mayor\u00eda de los casos, la parte de estas esperas de Exadata en el tiempo total de respuesta es baja, por lo que ni siquiera aparecen en la secci\u00f3n Top10 Foreground Events by Total Wait Time (en este caso, es necesario buscarlas en la secci\u00f3n Foreground Wait Events). Con gran dificultad, encontramos un ejemplo de AWR diario de nuestros clientes en el que las esperas de Exadata aparecieron en la secci\u00f3n Top10 y sumaron alrededor del 5%:<\/p>\n
Evento<\/strong><\/p>\n Esperas<\/strong><\/p>\n Tiempo total de espera (segundos)<\/strong><\/p>\n Tiempo promedio de espera<\/strong><\/p>\n % del tiempo DB<\/strong><\/p>\n Clase de espera<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115.2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net m\u00e1s datos de dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n Red<\/p>\n cell single block physical read<\/p>\n 5,661,452<\/p>\n 3827.6<\/p>\n 676.07us<\/p>\n 2.3<\/p>\n Usuario I\/O<\/p>\n Sincronizaci\u00f3n rebalanceo ASM<\/p>\n 4,350,012<\/p>\n 3481.3<\/p>\n 800.30us<\/p>\n 2.1<\/p>\n Otro<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2.96ms<\/p>\n 1.4<\/p>\n Usuario I\/O<\/p>\n lectura por ruta directa<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4.84ms<\/p>\n 1.1<\/p>\n Usuario I\/O<\/p>\n SQL*Net mensaje de dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n Red<\/p>\n cell smart table scan<\/p>\n 1,007,520<\/p>\n 1260.7<\/p>\n 1.25ms<\/p>\n 0.8<\/p>\n Usuario I\/O<\/p>\n lectura por ruta directa temporal<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1.55ms<\/p>\n 0.5<\/p>\n Usuario I\/O<\/p>\n enq: TM \u2014 contention<\/p>\n 652<\/p>\n 795.8<\/p>\n 1220.55ms<\/p>\n 0.5<\/p>\n Application<\/p>\n Con estad\u00edsticas de AWR as\u00ed, a menudo se hacen las siguientes conclusiones:<\/p>\n 1. La contribuci\u00f3n de la magia de Exadata al rendimiento de la base de datos no es alta \u2014 no supera el 5 %, y la base de datos \"exadatiza\" mal.<\/p>\n 2. Si se traslada tal base de datos de Exadata a una arquitectura cl\u00e1sica de \"servidor + matriz\", el rendimiento no cambiar\u00e1 mucho. Porque incluso si esta matriz resulta ser tres veces m\u00e1s lenta que el sistema de almacenamiento de Exadata (lo cual es poco probable para las matrices All Flash modernas), multiplicando 5% por tres obtendremos un aumento de la proporci\u00f3n de esperas de entrada\/salida del 15% \u2014 \u00a1esa base de datos seguramente lo soportar\u00e1!<\/p>\n Ambas estas salidas son imprecisas, adem\u00e1s distorsionan la comprensi\u00f3n de la idea subyacente en Exadata Software. Exadata no solo proporciona un r\u00e1pido rendimiento de entrada\/salida, sino que opera de manera fundamentalmente diferente en comparaci\u00f3n con la arquitectura cl\u00e1sica de \u00abservidor + matriz\u00bb. Si la base de datos realmente se \u00abexadatiza\u00bb, la l\u00f3gica SQL se traslada al sistema de almacenamiento. Storage servidores<\/a> gracias a una serie de mecanismos especializados (en primer lugar, Exadata Storage Indexes, pero no solo) encuentran los datos necesarios y los env\u00edan a los servidores de la base de datos. Lo hacen de manera bastante eficiente, por lo que la proporci\u00f3n de esperas caracter\u00edsticas de Exadata en el tiempo de respuesta total es peque\u00f1a. <\/p>\n \u00bfC\u00f3mo cambiar\u00e1 esta proporci\u00f3n fuera de Exadata? \u00bfC\u00f3mo afectar\u00e1 esto al rendimiento de la base de datos en general? Las pruebas responder\u00e1n mejor a estas preguntas. Por ejemplo, la espera de \u201ccell smart table scan\u201d fuera de Exadata puede convertirse en un pesado Table Full Scan, lo que significa que el rendimiento de entrada\/salida ocupar\u00e1 todo el tiempo de respuesta y el rendimiento se ver\u00e1 dr\u00e1sticamente afectado. Por eso es incorrecto, al analizar AWR, considerar el porcentaje total de esperas de Exadata como una contribuci\u00f3n m\u00e1gica al rendimiento, y mucho menos usar este porcentaje para prever el rendimiento fuera de Exadata. Para entender cu\u00e1n \u00abexadatizada\u00bb est\u00e1 la operaci\u00f3n de la base de datos, es necesario estudiar las estad\u00edsticas de la secci\u00f3n AWR \u201cInstance Activity Stats\u201d (donde hay muchas estad\u00edsticas con nombres elocuentes) y compararlas entre s\u00ed.<\/p>\n Y para entender c\u00f3mo se comportar\u00e1 la base de datos fuera de Exadata, lo mejor es crear un clon de la base desde una copia de seguridad en la arquitectura objetivo y analizar el rendimiento de este clon bajo carga. Esta posibilidad est\u00e1 generalmente disponible para quienes poseen Exadata.<\/p>\n