Referencia de las tablas y vistas de sistema
Temas
- Tablas y vistas de sistema
- Tipos de tablas y vistas de sistema
- Visibilidad de datos en las tablas y vistas de sistema
- Migración de consultas aprovisionadas solo a consultas de vista de supervisión de SYS
- Mejora del seguimiento de los identificadores de consultas mediante las vistas de monitoreo SYS
- Identificadores de consulta, proceso y sesión de tablas del sistema
- Vistas de metadatos SVV
- Vistas de monitoreo de SYS
- Asignación de la vista de sistema para migrar a las vistas de supervisión SYS
- Monitoreo del sistema (solo aprovisionado)
- Tablas de catálogos de sistema
Tablas y vistas de sistema
Amazon Redshift dispone de muchas tablas y vistas de sistema que contienen información acerca de cómo funciona el sistema. Puede consultar estas tablas y vistas de sistema de la misma forma que lo haría con cualquier otra tabla de bases de datos. En esta sección se muestran algunas consultas y explicaciones de ejemplo sobre las tablas de sistema:
-
Cómo se generan las diferentes vistas y tablas de sistema.
-
Qué tipos de información se puede obtener de estas tablas.
-
Cómo unir tablas de sistema de Amazon Redshift a tablas de catálogos
-
Cómo administrar el crecimiento de los archivos de registro de las tablas de sistema.
Algunas tablas de sistema solo pueden ser utilizadas por el personal de AWS con fines de diagnóstico. En las siguientes secciones se explican las tablas de sistema que los administradores del sistema u otros usuarios de la base de datos pueden consultar para obtener información útil.
nota
Las tablas de sistema no están incluidas en los backups de clústeres manuales o automáticos (instantáneas). Las vistas del sistema STL retienen siete días del historial de registros. La retención de registros no requiere ninguna acción por parte del cliente, pero si desea almacenar datos de registro durante más de siete días, deberá copiarlos periódicamente en otras tablas o descargarlos en Amazon S3.
Tipos de tablas y vistas de sistema
Existen varios tipos de tablas y vistas del sistema:
Las vistas SVV contienen información sobre los objetos de la base de datos con referencias a tablas STV transitorias.
Las vistas SYS se utilizan para monitorizar el uso de consultas y cargas de trabajo de los clústeres y grupos de trabajo sin servidor aprovisionados.
Las vistas STL se generan a partir de los registros que se han almacenado en el disco para proporcionar un historial del sistema.
Las tablas de STV son tablas de sistema virtuales que tienen instantáneas de los datos actuales del sistema. Están basadas en los datos transitorios en memoria y no se almacenan en los registros en disco o en las tablas normales.
Las vistas SVCS proporcionan información sobre las consultas de los clústeres principal y de escalado de simultaneidad.
Las vistas SVL proporcionan detalles sobre las consultas en los clústeres principales.
Las tablas y vistas de sistema no utilizan el mismo modelo de consistencia que las tablas normales. Es importante tener en cuenta este problema cuando se las consulta, en especial con las tablas STV y las vistas SVV. Por ejemplo, en el caso de una tabla t1 normal con una columna c1, se espera que la siguiente consulta no devuelva filas:
select * from t1 where c1 > (select max(c1) from t1)
No obstante, la siguiente consulta con una tabla de sistema puede devolver filas:
select * from stv_exec_state where currenttime > (select max(currenttime) from stv_exec_state)
La razón por la que esta consulta puede devolver filas es que currenttime es transitorio y las dos referencias de la consulta podrían no devolver el mismo valor cuando se evalúan.
Por otra parte, la siguiente consulta puede no devolver filas:
select * from stv_exec_state where currenttime = (select max(currenttime) from stv_exec_state)
Visibilidad de datos en las tablas y vistas de sistema
Existen dos clases de visibilidad para los datos de las tablas y vistas de sistema: visibilidad para los usuarios y visibilidad para los superusuarios.
Los usuarios con privilegios de superusuario son los únicos que pueden ver los datos de las tablas visibles para los superusuarios. Los usuarios normales pueden ver los datos de las tablas visibles para los usuarios. Para brindar a un usuario normal acceso a tablas visibles para los superusuarios, concédale el privilegio SELECT de esa tabla. Para obtener más información, consulte GRANT.
En las tablas visibles para los usuarios, de forma predeterminada, los usuarios normales no pueden ver las filas que generan otros usuarios. Si a un usuario normal se le concede SYSLOG ACCESS UNRESTRICTED, ese usuario podrá ver todas las filas de las tablas visibles para los usuarios, incluidas las que haya generado otro usuario. Para obtener más información, consulte ALTER USER o CREAR USUARIO. Todas las filas de SVV_TRANSACTIONS son visibles para todos los usuarios. Para obtener más información sobre la visibilidad de los datos, consulte el artículo de la base de conocimientos AWS re:Post ¿Cómo puedo conceder permiso a los usuarios normales de bases de datos de Amazon Redshift para ver los datos de las tablas del sistema de otros usuarios de mi clúster?
En el caso de las vistas de metadatos, Amazon Redshift no permite la visibilidad a los usuarios a los que se ha concedido SYSLOG ACCESS UNRESTRICTED.
nota
Al brindar a un usuario acceso sin restricciones a las tablas del sistema, le proporciona la visibilidad necesaria para ver los datos generados por otros usuarios. Por ejemplo, STL_QUERY y STL_QUERY_TEXT contienen todo el texto de las instrucciones INSERT, UPDATE y DELETE, que podrían contener datos confidenciales generados por los usuarios.
Un super usuario puede ver todas las filas de todas las tablas. Para brindar a un usuario normal acceso a una tabla visible para los superusuarios, concédale el privilegio GRANT SELECT de esta tabla.
Filtrado de consultas generadas por el sistema
Las tablas y las vistas de sistema relacionadas con las consultas, como SVL_QUERY_SUMMARY, SVL_QLOG y otras, suelen contener una gran cantidad de instrucciones generadas automáticamente que Amazon Redshift utiliza para supervisar el estado de la base de datos. Estas consultas generadas por el sistema son visibles para un super usuario, pero raramente son útiles. Para filtrarlas cuando se selecciona de una tabla de sistema o vista de sistema que utiliza la columna userid, agregue la condición userid > 1 a la cláusula WHERE. Por ejemplo:
select * from svl_query_summary where userid > 1
Migración de consultas aprovisionadas solo a consultas de vista de supervisión de SYS
Migración de clústeres aprovisionados a Amazon Redshift sin servidor
Si va a migrar un clúster aprovisionado a Amazon Redshift sin servidor, es posible que tenga consultas que utilicen las siguientes vistas del sistema, que solo almacenan datos de clústeres aprovisionados.
Todas las vistas STL
Todas las vistas STV
Todas las vistas SVCS
Todas las vistas SVL
Algunas vistas SVV
Para obtener una lista completa de las vistas SVV no compatibles en Amazon Redshift sin servidor, consulte la lista que aparece al final de Supervisión de consultas y cargas de trabajo con Amazon Redshift sin servidor en la Guía de administración de Amazon Redshift.
Para seguir utilizando sus consultas, reajústelas para utilizar las columnas definidas en las vistas de monitorización SYS que correspondan a las columnas de sus vistas aprovisionadas solo. Para ver la relación de asignación entre las vistas de solo aprovisionamiento y las vistas de supervisión de SYS, vaya a Asignación de la vista de sistema para migrar a las vistas de supervisión SYS
Actualización de consultas mientras se permanece en un clúster aprovisionado
Si no va a migrar a Amazon Redshift sin servidor, es posible que desee actualizar las consultas existentes. Las vistas de monitorización SYS están diseñadas para facilitar su utilización y reducir su complejidad, proporcionando una completa gama de métricas para monitorear y solucionar problemas de forma eficaz. Mediante vistas SYS como SYS_QUERY_HISTORY y SYS_QUERY_DETAIL que consolidan la información de varias vistas aprovisionadas solo, puede agilizar sus consultas.
Mejora del seguimiento de los identificadores de consultas mediante las vistas de monitoreo SYS
Las vistas de monitoreo SYS, como SYS_QUERY_HISTORY y SYS_QUERY_DETAIL, contienen la columna query_id, que incluye el identificador de las consultas de los usuarios. Del mismo modo, las vistas solo aprovisionadas, como STL_QUERY y SVL_QLOG, contienen la columna de consulta, que también incluye los identificadores de consultas. Sin embargo, los identificadores de consultas registrados en las vistas del sistema SYS son diferentes de los registrados en las vistas únicamente aprovisionadas.
La diferencia entre los valores de la columna query_id de las vistas SYS y los valores de las columnas de consulta de las vistas únicamente aprovisionadas es la siguiente:
En las vistas SYS, la columna query_id registra las consultas enviadas por los usuarios en su formato original. El optimizador de Amazon Redshift puede dividirlas en consultas secundarias para mejorar el rendimiento, pero si ejecuta una sola consulta esta seguirá teniendo una sola fila en SYS_QUERY_HISTORY. Si desea ver las consultas secundarias individuales, puede consultarlas en SYS_QUERY_DETAIL.
En las vistas únicamente aprovisionadas, la columna de consultas registra las consultas en el nivel de consulta secundaria. Si el optimizador de Amazon Redshift reescribe la consulta original en varias consultas secundarias, habrá varias filas en STL_QUERY con valores de identificador de consulta diferentes para una sola consulta que ejecute.
Cuando migre sus consultas de monitorep y diagnóstico de vistas únicamente aprovisionadas a vistas SYS, tenga en cuenta esta diferencia y edite las consultas en consecuencia. Para obtener más información sobre cómo procesa Amazon Redshift las consultas, consulte Flujo de trabajo de planificación y ejecución de consultas.
Ejemplo
Para ver un ejemplo de cómo Amazon Redshift registra las consultas de forma diferente en las vistas de supervisión de SYS y de solo aprovisionamiento, consulte la siguiente consulta de ejemplo. Esta es la consulta escrita tal y como la ejecutaría en Amazon Redshift.
SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.l_suppkey AND o_orderkey = l1.l_orderkey AND o_orderstatus = 'F' AND l1.l_receiptdate > l1.l_commitdate AND EXISTS (SELECT * FROM lineitem l2 WHERE l2.l_orderkey = l1.l_orderkey AND l2.l_suppkey <> l1.l_suppkey ) AND NOT EXISTS (SELECT * FROM lineitem l3 WHERE l3.l_orderkey = l1.l_orderkey AND l3.l_suppkey <> l1.l_suppkey AND l3.l_receiptdate > l3.l_commitdate ) AND s_nationkey = n_nationkey AND n_name = 'UNITED STATES' GROUP BY s_name ORDER BY numwait DESC , s_name LIMIT 100;
Internamente, el optimizador de consultas de Amazon Redshift reescribe la consulta anterior enviada por el usuario en cinco consultas secundarias.
La primera consulta secundaria crea una tabla temporal para materializar una subconsulta.
CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey , l_suppkey , s_name ) AS SELECT l1.l_orderkey , l1.l_suppkey , public.supplier.s_name FROM public.lineitem AS l1, public.nation, public.orders, public.supplier WHERE l1.l_commitdate < l1.l_receiptdate AND l1.l_orderkey = public.orders.o_orderkey AND l1.l_suppkey = public.supplier.s_suppkey AND public.nation.n_name = 'UNITED STATES'::CHAR(8) AND public.nation.n_nationkey = public.supplier.s_nationkey AND public.orders.o_orderstatus = 'F'::CHAR(1);
La segunda consulta secundaria recopila estadísticas de la tabla temporal.
padb_fetch_sample: select count(*) from volt_tt_606590308b512;
La tercera consulta secundaria crea otra tabla temporal para materializar otra subconsulta, que hace referencia a la tabla temporal creada anteriormente.
CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey , l_suppkey) AS (SELECT volt_tt_606590308b512.l_orderkey , volt_tt_606590308b512.l_suppkey FROM public.lineitem AS l2, volt_tt_606590308b512 WHERE l2.l_suppkey <> volt_tt_606590308b512.l_suppkey AND l2.l_orderkey = volt_tt_606590308b512.l_orderkey) EXCEPT distinct (SELECT volt_tt_606590308b512.l_orderkey, volt_tt_606590308b512.l_suppkey FROM public.lineitem AS l3, volt_tt_606590308b512 WHERE l3.l_commitdate < l3.l_receiptdate AND l3.l_suppkey <> volt_tt_606590308b512.l_suppkey AND l3.l_orderkey = volt_tt_606590308b512.l_orderkey);
La segunda consulta secundaria vuelve a recopilar las estadísticas de la tabla temporal.
padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
La última consulta secundaria utiliza las tablas temporales creadas anteriormente para generar el resultado.
SELECT volt_tt_606590308b512.s_name AS s_name , COUNT(*) AS numwait FROM volt_tt_606590308b512, volt_tt_606590308c2ef WHERE volt_tt_606590308b512.l_orderkey = volt_tt_606590308c2ef.l_orderkey AND volt_tt_606590308b512.l_suppkey = volt_tt_606590308c2ef.l_suppkey GROUP BY 1 ORDER BY 2 DESC , 1 ASC LIMIT 100;
En la vista de sistema STL_QUERY, únicamente aprovisionada, Amazon Redshift registra cinco filas en el nivel de consulta secundaria, de la siguiente manera:
SELECT userid, xid, pid, query, querytxt::varchar(100); FROM stl_query WHERE xid = 48237350 ORDER BY xid, starttime;userid | xid | pid | query | querytxt --------+----------+------------+----------+------------------------------------------------------------------------------------------------------ 101 | 48237350 | 1073840810 | 12058151 | CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey, l_suppkey, s_name) AS SELECT l1.l_orderkey, l1.l 101 | 48237350 | 1073840810 | 12058152 | padb_fetch_sample: select count(*) from volt_tt_606590308b512 101 | 48237350 | 1073840810 | 12058156 | CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey, l_suppkey) AS (SELECT volt_tt_606590308b512.l_or 101 | 48237350 | 1073840810 | 12058168 | padb_fetch_sample: select count(*) from volt_tt_606590308c2ef 101 | 48237350 | 1073840810 | 12058170 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1. (5 rows)
En la vista de monitoreo SYS SYS_QUERY_HISTORY, Amazon Redshift registra la consulta de la siguiente manera:
SELECT user_id, transaction_id, session_id, query_id, query_text::varchar(100) FROM sys_query_history WHERE transaction_id = 48237350 ORDER BY start_time;user_id | transaction_id | session_id | query_id | query_text ---------+----------------+------------+----------+------------------------------------------------------------------------------------------------------ 101 | 48237350 | 1073840810 | 12058149 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.
En SYS_QUERY_DETAIL, puede buscar detalles a nivel de consulta secundaria utilizando el valor query_id de SYS_QUERY_HISTORY. La columna child_query_sequence muestra el orden en que se ejecutan las consultas secundarias. Para obtener más información sobre las columnas de SYS_QUERY_DETAIL, consulte SYS_QUERY_DETAIL.
select user_id, query_id, child_query_sequence, stream_id, segment_id, step_id, start_time, end_time, duration, blocks_read, blocks_write, local_read_io, remote_read_io, data_skewness, time_skewness, is_active, spilled_block_local_disk, spilled_block_remote_disk from sys_query_detail where query_id = 12058149 and step_id = -1 order by query_id, child_query_sequence, stream_id, segment_id, step_id;user_id | query_id | child_query_sequence | stream_id | segment_id | step_id | start_time | end_time | duration | blocks_read | blocks_write | local_read_io | remote_read_io | data_skewness | time_skewness | is_active | spilled_block_local_disk | spilled_block_remote_disk ---------+----------+----------------------+-----------+------------+---------+----------------------------+----------------------------+----------+-------------+--------------+---------------+----------------+---------------+---------------+-----------+--------------------------+--------------------------- 101 | 12058149 | 1 | 0 | 0 | -1 | 2023-09-27 15:40:38.512415 | 2023-09-27 15:40:38.533333 | 20918 | 0 | 0 | 0 | 0 | 0 | 44 | f | 0 | 0 101 | 12058149 | 1 | 1 | 1 | -1 | 2023-09-27 15:40:39.931437 | 2023-09-27 15:40:39.972826 | 41389 | 12 | 0 | 12 | 0 | 0 | 77 | f | 0 | 0 101 | 12058149 | 1 | 2 | 2 | -1 | 2023-09-27 15:40:40.584412 | 2023-09-27 15:40:40.613982 | 29570 | 32 | 0 | 32 | 0 | 0 | 25 | f | 0 | 0 101 | 12058149 | 1 | 2 | 3 | -1 | 2023-09-27 15:40:40.582038 | 2023-09-27 15:40:40.615758 | 33720 | 0 | 0 | 0 | 0 | 0 | 1 | f | 0 | 0 101 | 12058149 | 1 | 3 | 4 | -1 | 2023-09-27 15:40:46.668766 | 2023-09-27 15:40:46.705456 | 36690 | 24 | 0 | 15 | 0 | 0 | 17 | f | 0 | 0 101 | 12058149 | 1 | 4 | 5 | -1 | 2023-09-27 15:40:46.707209 | 2023-09-27 15:40:46.709176 | 1967 | 0 | 0 | 0 | 0 | 0 | 18 | f | 0 | 0 101 | 12058149 | 1 | 4 | 6 | -1 | 2023-09-27 15:40:46.70656 | 2023-09-27 15:40:46.71289 | 6330 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 1 | 5 | 7 | -1 | 2023-09-27 15:40:46.71405 | 2023-09-27 15:40:46.714343 | 293 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 2 | 0 | 0 | -1 | 2023-09-27 15:40:52.083907 | 2023-09-27 15:40:52.087854 | 3947 | 0 | 0 | 0 | 0 | 0 | 35 | f | 0 | 0 101 | 12058149 | 2 | 1 | 1 | -1 | 2023-09-27 15:40:52.089632 | 2023-09-27 15:40:52.091129 | 1497 | 0 | 0 | 0 | 0 | 0 | 11 | f | 0 | 0 101 | 12058149 | 2 | 1 | 2 | -1 | 2023-09-27 15:40:52.089008 | 2023-09-27 15:40:52.091306 | 2298 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 3 | 0 | 0 | -1 | 2023-09-27 15:40:56.882013 | 2023-09-27 15:40:56.897282 | 15269 | 0 | 0 | 0 | 0 | 0 | 29 | f | 0 | 0 101 | 12058149 | 3 | 1 | 1 | -1 | 2023-09-27 15:40:59.718554 | 2023-09-27 15:40:59.722789 | 4235 | 0 | 0 | 0 | 0 | 0 | 13 | f | 0 | 0 101 | 12058149 | 3 | 2 | 2 | -1 | 2023-09-27 15:40:59.800382 | 2023-09-27 15:40:59.807388 | 7006 | 0 | 0 | 0 | 0 | 0 | 58 | f | 0 | 0 101 | 12058149 | 3 | 3 | 3 | -1 | 2023-09-27 15:41:06.488685 | 2023-09-27 15:41:06.493825 | 5140 | 0 | 0 | 0 | 0 | 0 | 56 | f | 0 | 0 101 | 12058149 | 3 | 3 | 4 | -1 | 2023-09-27 15:41:06.486206 | 2023-09-27 15:41:06.497756 | 11550 | 0 | 0 | 0 | 0 | 0 | 2 | f | 0 | 0 101 | 12058149 | 3 | 4 | 5 | -1 | 2023-09-27 15:41:06.499201 | 2023-09-27 15:41:06.500851 | 1650 | 0 | 0 | 0 | 0 | 0 | 15 | f | 0 | 0 101 | 12058149 | 3 | 4 | 6 | -1 | 2023-09-27 15:41:06.498609 | 2023-09-27 15:41:06.500949 | 2340 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 3 | 5 | 7 | -1 | 2023-09-27 15:41:06.502945 | 2023-09-27 15:41:06.503282 | 337 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 4 | 0 | 0 | -1 | 2023-09-27 15:41:06.62899 | 2023-09-27 15:41:06.631452 | 2462 | 0 | 0 | 0 | 0 | 0 | 22 | f | 0 | 0 101 | 12058149 | 4 | 1 | 1 | -1 | 2023-09-27 15:41:06.632313 | 2023-09-27 15:41:06.63391 | 1597 | 0 | 0 | 0 | 0 | 0 | 20 | f | 0 | 0 101 | 12058149 | 4 | 1 | 2 | -1 | 2023-09-27 15:41:06.631726 | 2023-09-27 15:41:06.633813 | 2087 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 5 | 0 | 0 | -1 | 2023-09-27 15:41:12.571974 | 2023-09-27 15:41:12.584234 | 12260 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0 101 | 12058149 | 5 | 0 | 1 | -1 | 2023-09-27 15:41:12.569815 | 2023-09-27 15:41:12.585391 | 15576 | 0 | 0 | 0 | 0 | 0 | 4 | f | 0 | 0 101 | 12058149 | 5 | 1 | 2 | -1 | 2023-09-27 15:41:13.758513 | 2023-09-27 15:41:13.76401 | 5497 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0 101 | 12058149 | 5 | 1 | 3 | -1 | 2023-09-27 15:41:13.749 | 2023-09-27 15:41:13.772987 | 23987 | 0 | 0 | 0 | 0 | 0 | 32 | f | 0 | 0 101 | 12058149 | 5 | 2 | 4 | -1 | 2023-09-27 15:41:13.799526 | 2023-09-27 15:41:13.813506 | 13980 | 0 | 0 | 0 | 0 | 0 | 62 | f | 0 | 0 101 | 12058149 | 5 | 2 | 5 | -1 | 2023-09-27 15:41:13.798823 | 2023-09-27 15:41:13.813651 | 14828 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 (28 rows)
Identificadores de consulta, proceso y sesión de tablas del sistema
Al analizar los identificadores de consulta, proceso y sesión que aparecen en las tablas del sistema, tenga en cuenta lo siguiente:
El valor del identificador de consulta (en columnas como
query_idyquery) se puede reutilizar con el tiempo.El valor del identificador de proceso o sesión (en columnas como
process_id,pidysession_id) se puede reutilizar con el tiempo.El valor del identificador de la transacción (en columnas como
transaction_idyxid) es único.
