Desafortunadamente, ahora el papel de los especialistas en el ajuste del rendimiento y la solución de problemas de la base de datos se reduce solo a la última: solución de problemas: casi siempre recurren a especialistas solo cuando los problemas ya han llegado a un punto crítico, y deben resolverse "ayer". Y aun así, es bueno si se vuelven y no posponen el problema comprando un hardware aún más caro y potente sin una auditoría de rendimiento detallada y pruebas de estrés. De hecho, las frustraciones a menudo son suficientes: compraron equipos que valían entre 2 y 5 veces más caros, y ganaron solo un 30-40% en rendimiento, cuyo aumento total se consume en unos pocos meses, ya sea por un aumento en el número de usuarios o por un aumento exponencial de datos, junto con una complicación de la lógica.
Y ahora, en un momento en que el número de arquitectos, probadores e ingenieros de DevOps está creciendo rápidamente, y los desarrolladores de Java Core están optimizando incluso el trabajo
con cadenas , lenta pero seguramente llega el momento de los optimizadores de bases de datos. Los DBMS con cada versión se vuelven más inteligentes y complejos que estudiar matices y optimizaciones documentados e indocumentados requiere una gran cantidad de tiempo. Se publica una gran cantidad de artículos mensualmente y se llevan a cabo importantes conferencias dedicadas a Oracle. Perdón por la analogía banal, pero en esta situación, cuando los administradores de bases de datos se vuelven similares a los pilotos de aviones con innumerables interruptores, botones, luces y pantallas, ya es indecente cargarlos con las sutilezas de la optimización del rendimiento.
Por supuesto, DBA, al igual que los pilotos, en la mayoría de los casos puede resolver fácilmente problemas obvios y simples cuando se diagnostican fácilmente o se notan en varias "partes superiores" (eventos principales, SQL superior, segmentos superiores ...). Y que son fáciles de encontrar en MOS o Google, incluso si no conocen la solución. Es mucho más complicado cuando incluso los síntomas están ocultos detrás de la complejidad del sistema y necesitan ser rescatados entre la gran cantidad de información de diagnóstico recopilada por el propio DBMS de Oracle.
Uno de los ejemplos más simples y vívidos es el análisis de filtros y predicciones de acceso: en sistemas grandes y cargados, a menudo sucede que tal problema se pasa por alto fácilmente, porque la carga se distribuye de manera bastante uniforme en diferentes solicitudes (con combinaciones para varias tablas, con ligeras diferencias en las condiciones, etc.), y los segmentos superiores no muestran nada especial, diciendo: "bueno, sí, los datos de estas tablas se necesitan con mayor frecuencia y hay más" . En tales casos, puede comenzar el análisis con estadísticas desde SYS.COL_USAGE $:
col_usage.sqlcol owner format a30 col oname format a30 heading "Object name" col cname format a30 heading "Column name" accept owner_mask prompt "Enter owner mask: "; accept tab_name prompt "Enter tab_name mask: "; accept col_name prompt "Enter col_name mask: "; SELECT a.username as owner ,o.name as oname ,c.name as cname ,u.equality_preds as equality_preds ,u.equijoin_preds as equijoin_preds ,u.nonequijoin_preds as nonequijoin_preds ,u.range_preds as range_preds ,u.like_preds as like_preds ,u.null_preds as null_preds ,to_char(u.timestamp, 'yyyy-mm-dd hh24:mi:ss') when FROM sys.col_usage$ u , sys.obj$ o , sys.col$ c , all_users a WHERE a.user_id = o.owner
Sin embargo, para un análisis completo de esta información no es suficiente, porque no muestra combinaciones de predicados. En este caso, el análisis de v $ active_session_history y v $ sql_plan puede ayudarnos:
with ash as ( select sql_id ,plan_hash_value ,table_name ,alias ,ACCESS_PREDICATES ,FILTER_PREDICATES ,count(*) cnt from ( select h.sql_id ,h.SQL_PLAN_HASH_VALUE plan_hash_value ,decode(p.OPERATION ,'TABLE ACCESS',p.OBJECT_OWNER||'.'||p.OBJECT_NAME ,(select i.TABLE_OWNER||'.'||i.TABLE_NAME from dba_indexes i where i.OWNER=p.OBJECT_OWNER and i.index_name=p.OBJECT_NAME) ) table_name ,OBJECT_ALIAS ALIAS ,p.ACCESS_PREDICATES ,p.FILTER_PREDICATES
Como puede ver en la consulta en sí, muestra las 50 principales columnas de búsqueda y los predicados en sí mismos por la cantidad de veces que ASH acierta en las últimas 3 horas. A pesar de que ASH solo almacena instantáneas cada segundo, el muestreo en bases cargadas es muy representativo. Puede aclarar varios puntos:
- El campo cols: muestra las columnas de búsqueda y total_by_cols: la suma de las entradas en el contexto de estas columnas.
- Creo que es bastante obvio que esta información en sí misma no es un marcador suficiente del problema, porque por ejemplo, varios escaneos completos de una sola vez pueden arruinar fácilmente las estadísticas, por lo que definitivamente tendrá que considerar las consultas en sí y su frecuencia (v $ sqlstats, dba_hist_sqlstat)
- Agrupando por OBJECT_ALIAS dentro de SQL_ID, plan_hash_value es importante para combinar predicados de índice y tabla por objeto, porque Al acceder a la tabla a través del índice, los predicados se dividirán en diferentes líneas del plan:
Dependiendo de la necesidad, este script se puede modificar fácilmente para recopilar información adicional en otras secciones, por ejemplo, teniendo en cuenta la partición o las expectativas. Y después de analizar esta información, junto con el análisis de las estadísticas de la tabla y sus índices, el esquema general de datos y la lógica de negocios, puede pasar recomendaciones a los desarrolladores o arquitectos para elegir una solución, por ejemplo: opciones para la desnormalización o cambiar el esquema o los índices de partición.
También a menudo se olvida analizar el tráfico de red SQL *, y también hay muchas sutilezas, por ejemplo: tamaño de captura, SQLNET.COMPRESSION, tipos de datos extendidos, que permiten reducir la cantidad de viajes redondos, etc., pero este es un tema para un artículo separado.
En conclusión, me gustaría decir que ahora que los usuarios se vuelven menos tolerantes a los retrasos, la optimización del rendimiento se está convirtiendo en una ventaja competitiva.