Referência de visualizações e tabelas do sistema
O Amazon Redshift tem muitas tabelas de sistema e visualizações que contêm informações sobre como o sistema está funcionando. Você pode consultar essas tabelas de sistema e visualizações da mesma maneira como consultaria qualquer outra tabela de banco de dados. Esta seção mostra algumas consultas de tabela de sistema de exemplo e explica:
-
Como tipos diferentes de tabelas de sistema e visualizações são gerados
-
Quais tipos de informações você pode obter dessas tabelas
-
Como unir tabelas de sistema do Amazon Redshift a tabelas de catálogo
-
Como gerenciar o crescimento de arquivos de log da tabela de sistema
Algumas tabelas de sistema somente podem ser usadas pela equipe da AWS para fins de diagnóstico. As seções a seguir abordam as tabelas de sistema que podem ser consultadas em busca de informações úteis por administradores de sistema ou outros usuários do banco de dados.
nota
As tabelas de sistema não estão incluídas em backups de cluster automatizados ou manuais (snapshots). As visualizações do sistema STL retêm sete dias do histórico de log. Reter os logs não requer nenhuma ação do cliente, mas se você quiser reter os dados de log por mais de sete dias, será necessário copiá-los periodicamente para outras tabelas ou descarregá-los no Amazon S3.
Tópicos
- Tipos de tabelas e visualizações de sistema
- Visibilidade de dados em tabelas e visualizações de sistema
- Migrar consultas somente provisionadas para consultas de visualização de monitoramento de SYS
- Melhoria do rastreamento do identificador de consultas usando as exbições de monitoramento SYS
- IDs de consulta, de processo e de sessão de tabelas do sistema
- Visualizações SVV de metadados
- Visualizações de monitoramento de SYS
- Mapeamento de visualizações do sistema para migrar para visualizações de monitoramento de SYS
- Monitoramento do sistema (somente provisionado)
- Tabelas de catálogo do sistema
Tipos de tabelas e visualizações de sistema
Há vários tipos de tabelas e visões do sistema:
-
As visualizações SVV contêm informações sobre objetos de banco de dados com referências a tabelas STV transitórias.
-
As visualizações SYS são usadas para monitorar o uso de consultas e workload para clusters e grupos de trabalho sem servidor.
-
As tabelas STL são geradas a partir de logs que foram mantidos em disco para apresentar um histórico do sistema.
-
Essas tabelas de STV são tabelas virtuais do sistema que contêm snapshots dos dados atuais do sistema. Elas se baseiam em dados transitórios na memória e não são mantidas em logs baseados em disco ou em tabelas regulares.
-
As visões SVCS fornecem detalhes sobre consultas nos clusters principal e de escalabilidade da simultaneidade.
-
As visualizações SVL fornecem detalhes sobre consultas nos clusters principais.
As tabelas de sistema e as visualizações não usam o mesmo modelo de consistência de tabelas regulares. É importante estar ciente desse problema ao consultá-las, especialmente para tabelas STV e visualizações SVV. Por exemplo, dada uma tabela t1 regular com uma coluna c1, você esperaria que a seguinte consulta não retornasse linhas:
select * from t1 where c1 > (select max(c1) from t1)
Porém, a seguinte consulta em relação a uma tabela de sistema também pode retornar linhas:
select * from stv_exec_state where currenttime > (select max(currenttime) from stv_exec_state)
O motivo dessa consulta poder retornar linhas é que currenttime é temporário e as duas referências na consulta talvez não retornem o mesmo valor quando avaliadas.
Por outro lado, a seguinte consulta também pode não retornar linhas:
select * from stv_exec_state where currenttime = (select max(currenttime) from stv_exec_state)
Visibilidade de dados em tabelas e visualizações de sistema
Existem duas classes de visibilidade para dados em tabelas e exibições do sistema: visível para usuários e visível para superusuários.
Somente usuários com privilégios de superusuário podem ver os dados dessas tabelas que estejam na categoria visível para superusuários. Os usuários regulares podem ver dados em tabelas visíveis para usuários. Para oferecer a um usuário regular acesso às tabelas visíveis aos superusuários, conceda o privilégio SELECT nessa tabela ao usuário regular. Para ter mais informações, consulte GRANT.
Por padrão, na maioria das tabelas visíveis para usuários, as linhas geradas por um outro usuário são invisíveis para um usuário regular. Se um usuário regular receber SYSLOG ACCESS UNRESTRICTED, ele poderá ver todas as linhas em tabelas visíveis aos usuários, incluindo as linhas geradas por outros usuários. Para obter mais informações, consulte ALTER USER ou CRIAR USUÁRIO. Todas as linhas em SVV_TRANSACTIONS são visíveis a todos os usuários. Para obter informações sobre visibilidade de dados, consulte o artigo AWS re:Post Como posso permitir que usuários regulares do banco de dados Amazon Redshift visualizem dados em tabelas do sistema de outros usuários do cluster?
Para visualizações de metadados, o Amazon Redshift não permite visibilidade para usuários que recebem SYSLOG ACCESS UNRESTRICTED.
nota
Fornecer acesso ilimitado para um usuário às tabelas de sistema é o mesmo que dar ao usuário visibilidade para os dados gerados por outros usuários. Por exemplo, STL_QUERY e STL_QUERY_TEXT contêm texto completo de instruções INSERT, UPDATE e DELETE, e podem conter dados confidenciais gerados pelos usuários.
Um superusuário pode ver todas as linhas em todas as tabelas. Para oferecer acesso a um usuário regular às tabelas visíveis para superusuários, GRANTselecione o privilégio nessa tabela para o usuário regular.
Filtrar consultas geradas pelo sistema
As tabelas e visualizações do sistema relacionadas à consulta, como SVL_QUERY_SUMMARY, SVL_QLOG e outras, geralmente contêm um grande número de instruções geradas automaticamente que o Amazon Redshift usa para monitorar o status do banco de dados. Essas consultas geradas pelo sistema são visíveis para um superusuário, mas raramente são úteis. Para filtrá-las ao selecionar uma tabela ou visualização de sistema que use a coluna userid, adicione a condição userid > 1 à cláusula WHERE. Por exemplo:
select * from svl_query_summary where userid > 1
Migrar consultas somente provisionadas para consultas de visualização de monitoramento de SYS
Migrar clusters provisionados para o Amazon Redshift sem servidor
Se você estiver migrando um cluster provisionado para o Amazon Redshift sem servidor, poderá ter consultas usando as visualizações do sistema a seguir, que só armazenam dados de clusters provisionados.
-
Todas as visualizações STL
-
Todas as visualizações STV
-
Todas as visualizações SVCS
-
Todas as visualizações SVL
-
Algumas visualizações SVV
-
Para ter uma lista completa de visualizações SVV não aceitas no Amazon Redshift sem servidor, consulte a lista na parte inferior de Monitorar consultas e workloads com o Amazon Redshift Serverless no Guia de gerenciamento do Amazon Redshift.
-
Para continuar usando suas consultas, redefina-as para utilizar colunas definidas nas visualizações de monitoramento de SYS que correspondam às colunas em suas visualizações somente provisionadas. Para ver a relação de mapeamento entre as visualizações somente provisionadas e as visualizações de monitoramento de SYS, acesse Mapeamento de visualizações do sistema para migrar para visualizações de monitoramento de SYS.
Atualizar consultas enquanto estiver em um cluster provisionado
Se você não estiver migrando para o Amazon Redshift sem servidor, ainda assim deveria atualizar as consultas existentes. As visualizações de monitoramento de SYS foram projetadas para serem fáceis de usar e diminuir a complexidade, fornecendo um conjunto completo de métricas para contribuir para a eficácia de monitoramento e solução de problemas. Usando visualizações SYS como SYS_QUERY_HISTORY e SYS_QUERY_DETAIL, que consolidam as informações de várias visualizações somente provisionadas, você pode simplificar suas consultas.
Melhoria do rastreamento do identificador de consultas usando as exbições de monitoramento SYS
As exibições de monitoramento SYS, como SYS_QUERY_HISTORY e SYS_QUERY_DETAIL, contêm a coluna query_id, que contém o identificador das consultas dos usuários. Da mesma forma, as exibições somente provisionadas, como STL_QUERY e SVL_QLOG, contêm a coluna de consulta, que também contém os identificadores de consulta. No entanto, os identificadores de consulta registrados nas exibições de sistema SYS são diferentes daqueles registrados nas exibições somente provisionadas.
A diferença entre os valores da coluna query_id das exibições SYS e os valores da coluna de consulta das exibições somente provisionadas é a seguinte:
-
Em exibições SYS, a coluna query_id registra as consultas enviadas pelo usuário no formato original. O otimizador do Amazon Redshift pode dividi-las em consultas secundárias tendo em vista um desempenho melhor, mas uma única consulta executada por você ainda terá apenas uma única linha em SYS_QUERY_HISTORY. Se quiser ver as consultas filho individuais, você poderá encontrá-las em SYS_QUERY_DETAIL.
-
Em exibições somente provisionadas, a coluna de consulta registra consultas no nível da consulta filho. Se o otimizador do Amazon Redshift reescrever a consulta original em várias consultas filho, haverá várias linhas em STL_QUERY com valores identificadores de consulta diferentes para uma única consulta executada por você.
Ao migrar as consultas de monitoramento e diagnóstico de exibições somente provisionadas para exibições SYS, considere essa diferença e edite as consultas de acordo. Para obter mais informações sobre como o Amazon Redshift processa as consultas, consulte Planejamento de consulta e fluxo de trabalho de execução.
Exemplo
Para ver um exemplo de como o Amazon Redshift registra consultas de maneira diferente em visualizações somente provisionadas e de monitoramento de SYS, consulte o exemplo de consulta a seguir. Esta é a consulta escrita como você a executaria no 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;
Nos bastidores, o otimizador de consultas do Amazon Redshift reescreve a consulta enviada pelo usuário acima em cinco consultas filho.
A primeira consulta filho cria uma tabela temporária para materializar uma 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);
A segunda consulta filho coleta estatísticas da tabela temporária.
padb_fetch_sample: select count(*) from volt_tt_606590308b512;
A terceira consulta filho cria outra tabela temporária para materializar outra subconsulta, referenciando a tabela temporária criada acima.
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);
A quarta consulta filho coleta novamente estatísticas da tabela temporária.
padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
A última consulta filho usa as tabelas temporárias criadas acima para gerar a saída.
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;
Na exibição do sistema somente provisionada STL_QUERY, o Amazon Redshift registra cinco linhas no nível da consulta filho, da seguinte maneira:
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)
Na exibição de monitoramento SYS SYS_QUERY_HISTORY, o Amazon Redshift registra a consulta da seguinte maneira:
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.
Em SYS_QUERY_DETAIL, você pode encontrar detalhes no nível da consulta filho usando o valor query_id de SYS_QUERY_HISTORY. A coluna child_query_sequence mostra a ordem na qual as consultas filho são executadas. Para obter mais informações sobre as colunas em 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)
IDs de consulta, de processo e de sessão de tabelas do sistema
Ao analisar os IDs de consulta, de processo e de sessão que aparecem nas tabelas do sistema, esteja ciente do seguinte:
-
O valor do ID de consulta (em colunas, como
query_idequery) pode ser reutilizado ao longo do tempo. -
O valor do ID de processo ou de sessão (em colunas, como
process_id,pidesession_id) pode ser reutilizado ao longo do tempo. -
O valor do ID de transação (em colunas, como
transaction_idexid) é exclusivo.
