vertica数据库监控
周锐
系统健康监控
节点状态监控
可通过命令查看系统表nodes，获得各个节点的健康状态。
=> SELECT node_name, node_state FROM nodes ORDER BY 1;
node_name | node_state
----------------+------------
v_demo_node0001 | UP
v_demo_node0002 | INITALIZING
v_demo_node0003 | UP
(3 rows)
也可以通过Management Console更直观的查看各个节点的健康状态。
监控epoch状态
通过查看系统表system，获得urrent_epoch, ahm_epoch, last_good_epoch等信息。事实上，你可以从system系统表，获取到很多有用的信息。如designed_fault_tolerance即为系统的K-safe值。
=> SELECT current_epoch, ahm_epoch, last_good_epoch, designed_fault_tolerance, current_fault_tolerance, wos_used_bytes, ros_used_bytes FROM system;
Current_epoch | ahm_epoch | last_good_epoch | designed_fault_tolerance | current_fault_tolerance | wos_used_bytes | ros_used_bytes
----------------+-----------+-----------------+--------------------------+-------------------------+----------------+----------------
1176 | 1175 | 1175 | 0 | 0 | 0 | 310675364
(1 row)
或者，您也可以使用以下查询：
=> SELECT get_ahm_time()，get_ahm_epoch()，get_last_good_epoch()，get_current_epoch()，sysdate;
ahm_epoch接近last_good_epoch吗？如果ahm_epoch离last_good_epoch很远，那么ancient history标志就不会更新。
监控删除矢量
当在表上运行单个DELETE或UPDATE语句时，Vertica会创建删除向量。大量删除向量会对数据库的性能产生负面影响。使用以下查询收集系统的删除向量总数：
=> SELECT COUNT(*)FROM v_monitor.delete_vectors;
=> SELECT node_name, schema_name, projection_name, total_row_count, deleted_row_count, delete_vector_count FROM storage_containers WHERE deleted_row_count > total_row_count*.05::float ORDER BY deleted_row_count desc;
node_name | schema_name | projection_name | total_row_count | deleted_row_count | delete_vector_count
----------------+-------------+-----------------------+-----------------+-------------------+---------------------
v_demo_node0001 | public | customer_dimension_b0 | 16906 | 16906 | 1
v_demo_node0002 | public | customer_dimension_b1 | 16906 | 16906 | 1
v_demo_node0001 | public | customer_dimension_b1 | 16654 | 16654 | 1
v_demo_node0003 | public | customer_dimension_b0 | 16654 | 16654 | 1
...
大量删除向量表示群集处于故障状态。要管理删除向量，请参阅Vertica知识库中删除数据的最佳实践。
监视ROS容器的数量
Vertica的每个投影的上限阈值为1024个ROS容器。如果数据库中的ROS容器数量过多，则会对性能产生负面影响。因此，您应该监视ROS容器的数量。使用以下查询查看每个节点每个投影的ROS容器数：
=> SELECT node_name, projection_schema, projection_name, SUM(ros_count) AS ros_count FROM v_monitor.projection_storage GROUP BY node_name, projection_schema, projection_name ORDER BY ros_count DESC;
node_name | projection_schema | projection_name | ros_count
-----------------+-------------------+-----------------------------+-----
v_vmart_node0001 | public | t11_super | 3
v_vmart_node0001 | public | tab3_super | 2
v_vmart_node0001 | public | tab3_ukcol2 | 2
v_vmart_node0001 | public | shipping_dimension_super | 1
v_vmart_node0001 | public | small_input_impute_super | 1
v_vmart_node0001 | store | store_dimension_super | 1
v_vmart_node0002 | public | small_input_impute_super | 1
v_vmart_node0002 | public | shipping_dimension_super | 1
v_vmart_node0001 | public | small_input_impute1_super | 1
v_vmart_node0001 | public | vlog_super | 1
v_vmart_node0002 | public | tab3_super | 1
v_vmart_node0002 | public | visitsTemp_super | 1
v_vmart_node0003 | public | target_super | 1
v_vmart_node0003 | public | students_super | 1
v_vmart_node0001 | public | bar_super | 1
v_vmart_node0003 | public | vendor_dimension_super | 1
v_vmart_node0003 | public | shipping_dimension_super | 1
v_vmart_node0002 | public | vlog_super | 1
v_vmart_node0003 | public | mtcars_predict_svm_super | 1
v_vmart_node0001 | online_sales | call_center_dimension_super | 1
大量（超过500个）ROS容器表示表的PARTITION BY子句存在问题。它还可以表明合并过程不起作用。
资源使用
监视资源池
资源池允许Vertica管理处理器和内存资源。Vertica提供用于执行查询的内置资源池。如果工作负载需要，您还可以创建自己的资源池。使用以下查询检查资源池的状态：
=> SELECT sysdate AS current_time, node_name, pool_name, memory_inuse_kb,
general_memory_borrowed_kb, running_query_count FROM resource_pool_status
WHERE pool_name IN ('general') ORDER BY 1,2,3;
current_time | node_name | pool_name | memory_inuse_kb | general_memory_borrowed_kb | running_query_count
---------------------------+-----------------+-----------+-----------------+----------------------------+---------------------
2017-04-14 13:49:22.630529 | v_demo_node0001 | general | 7132121 | 0 | 3
2017-04-14 13:49:22.630529 | v_demo_node0002 | general | 7133456 | 0 | 3
2017-04-14 13:49:22.630529 | v_demo_node0003 | general | 7133261 | 0 | 3
(3 rows)
此查询提供有关每个资源池的内存使用情况以及每个资源池上运行的查询数的信息。监视查询是否占用过多内存资源并导致群集速度变慢：
=> SELECT * FROM resource_acquisitions ORDER BY memory_inuse_kb desc limit X;
监视资源池队列状态
您可以通过监视资源池来检查是否有任何事务排队。使用以下查询显示所有资源队列：
=> SELECT * FROM v_monitor.resource_queues;
node_name | transaction_id | statement_id | pool_name | memory_requested_kb | priority | position_in_queue | queue_entry_timestamp
----------------+-------------------+--------------+-----------+---------------------+----------+-------------------+-------------------------------
v_demo_node0001 | 45035996273705862 | 1 | general | 2374617 | 0 | 1 | 2017-04-14 13:53:44.042381+09
v_demo_node0002 | 45035996273705862 | 1 | general | 2375067 | 0 | 1 | 2017-04-14 13:53:44.04009+09
v_demo_node0003 | 45035996273705862 | 1 | general | 2374998 | 0 | 1 | 2017-04-14 13:53:44.034676+09
(3 rows)
资源队列提供有关各种资源池的待处理请求的信息。
监视资源请求拒绝
您可以使用以下查询检查资源请求拒绝：
=> SELECT * FROM v_monitor.resource_rejections;
node_name | pool_id | pool_name | reason | resource_type | rejection_count | first_rejected_timestamp | last_rejected_timestamp | last_rejected_value
-----------------+-------------------+-----------+-----------------------------+---------------+-----------------+-------------------------------+-------------------------------+----------------------
v_vmart_node0001 | 45035996273704996 | general | Request exceeded high limit | Memory(KB) | 1 | 2017-02-21 13:10:42.873417-05 | 2017-02-21 13:10:42.873417-05 | 3140435
v_vmart_node0002 | 45035996273704996 | general | Request exceeded high limit | Memory(KB) | 1 | 2017-02-21 13:10:42.873334-05 | 2017-02-21 13:10:42.873334-05 | 3111145
v_vmart_node0003 | 45035996273704996 | general | Request exceeded high limit | Memory(KB) | 1 | 2017-02-21 13:10:42.878341-05 | 2017-02-21 13:10:42.878341-05 | 3111143
Vertica监视资源管理器拒绝的资源请求。仅当节点启动且节点重新启动时计数器已重置为0时，信息才有效。此信息对于确定是否存在资源空间问题以及哪些用户/池遇到问题很有用。监视系统资源Vertica提供了系统表，使您可以监视数据库并跟踪系统资源瓶颈。
=> SELECT * FROM v_monitor.system_resource_usage ORDER BY end_time DESC;
node_name | end_time | average_memory_usage_percent | average_cpu_usage_percent | net_rx_kbytes_per_second | net_tx_kbytes_per_second | io_read_kbytes_per_second | io_written_kbytes_per_second
----------------- + --------------------- + --------- --------------------- + --------------------------- + -------------------------- + ----------------------- --- + --------------------------- + ------------------ -------------
v_vmart_node0001 | 2017-04-13 10:08:00 | 23.97 | 51.6 | 72.89 | 0.9 | 0 | 286.8
v_vmart_node0002 | 2017-04-13 10:08:00 | 9.88 | 0.84 | 72.14 | 0.26 | 0 | 255.47
v_vmart_node0003 | 2017-04-13 10:08:00 | 9.7 | 0.94 | 72.14 | 0.27 | 0 | 214
v_vmart_node0001 | 2017-04-13 10:07:00 | 23.97 | 51.81 | 105.23 | 0.84 | 0 | 272.06
v_vmart_node0002 | 2017-04-13 10:07:00 | 9.88 | 0.9 | 104.42 | 0.31 | 0 | 264.96
v_vmart_node0003 | 2017-04-13 10:07:00 | 9.72 | 0.95 | 104.51 | 0.22 | 0 | 267.63
v_vmart_node0001 | 2017-04-13 10:06:00 | 23.97 | 51.82 | 101.15 | 1.12 | 0 | 284.23
···
系统资源使用系统表提供有关系统资源的历史记录，例如内存，CPU，网络，磁盘，I / O。 监视存储空间Vertica建议您有40％的可用空间，以便Vertica顺利运行。使用以下查询监控存储空间可用性：
=> SELECT * FROM v_monitor.storage_usage ORDER BY poll_timestamp DESC;
poll_timestamp | node_name | path | device | filesystem | used_bytes | free_bytes | usage_percent
------------------------------+------------------+------+-----------+------------+-------------+-------------+-------------------------
2017-03-20 12:02:00.008656-04 | v_vmart_node0002 | | | vertica | 10454126592 | 40141549568 | 20.66000000000000000000
2017-03-20 12:02:00.008653-04 | v_vmart_node0002 | /dev | devtmpfs | devtmpfs | 151552 | 1997717504 | 0.01000000000000000000
2017-03-20 12:02:00.008648-04 | v_vmart_node0002 | / | /dev/sda2 | ext4 | 10454142976 | 40141533184 | 20.66000000000000000000
2017-03-20 12:02:00.00563-04 | v_vmart_node0001 | | | vertica | 17218465792 | 33377210368 | 34.03000000000000000000
2017-03-20 12:02:00.005629-04 | v_vmart_node0001 | /dev | devtmpfs | devtmpfs | 151552 | 1997725696 | 0.01000000000000000000
存储使用系统表提供有关文件系统存储使用情况的信息。这对于确定磁盘空间使用趋势非常有用。
活动会话
监控活动会话
用户可以同时连接到多个正在运行的会话。多个活动用户会话可能会影响群集性能。使用以下查询，监视当前处于活动状态的会话：
=> SELECT user_name, session_id, current_statement, statement_start FROM v_monitor.sessions;
user_name | session_id | current_statement | statement_start
----------+-------------------------------+-------------------------------------------------------------------------------------------+------------------------------
dbadmin | v_vmart_node0001-73892:0x3b52 | | 2017-03-21 11:32:50.029212-04
dbadmin | v_vmart_node0001-73892:0x5e78 | SELECT user_name, session_id, current_statement, statement_start FROM v_monitor.sessions; | 2017-03-21 16:22:19.145425-04
(2 rows)
监视器会话系统表监视外部会话。使用此表：
- 识别正在运行长查询的用户。
- 识别由于空闲但未提交的事务而持有锁的用户。
- 在关闭数据库之前确定要断开连接的用户。
- 确定用于特定会话的数据库安全性的详细信息，安全套接字层（SSL）或客户端身份验证。
- 识别特定于客户端的信息，例如客户端版本。
关闭活动会话
关闭会话会中断指定的外部会话，如果有则回滚当前事务，并关闭套接字。您只能关闭自己的会话。会话结束可能需要一些时间。
=> SELECT close_session ('session id');
CLOSE_SESSION
--------------------------------------------------------------------
Session close command sent. Check v_monitor.sessions for progress.
(1 row)
会话ID是一个字符串，用于指定要关闭的会话。此标识符在任何时间点都在群集中是唯一的，但可以在会话关闭时重复使用。
活动查询
监视正在运行的查询
查询配置文件提供有关已执行查询，使用以下查询获取此刻执行的查询列表：
=> SELECT node_name，query，query_start，user_name，is_executing FROM v_monitor.query_profiles WHERE is_executing ='t';
node_name | query| query_start | user_name | is_executing
----------------- + ------------------------------- -------------------------------------------------- ---------------------------- + --------------------- ---------- + ----------- + --------------
v_vmart_node0001 | SELECT node_name，query，query_start，user_name，is_executing FROM query_profiles WHERE is_executing ='t'; | 2017-04-18 10:54：47.976406-04 | dbadmin | t
结果显示连接到数据库的用户（user_name）以及它们正在运行的查询（查询）。您还可以查看查询开始时间（query_start）以及查询开始运行的位置（node_name）。结果可帮助您了解群集的当前工作负载。
监控负载状态
使用以下查询检查活动和历史查询的加载进度：
=> SELECT table_name，read_bytes，input_file_size_bytes，accepted_row_count，rejected_row_count，parse_complete_percent，sort_complete_percent FROM load_streams WHERE is_executing ='t' ORDER BY table_name;
table_name | read_bytes | input_file_size_bytes | accepted_row_count | rejected_row_count | parse_complete_percent | sort_complete_percent
----------------- + ------------ + ------------------ ----- + -------------------- + -------------------- + - ---------------------- + -----------------------
store_sales_fact | 375766803 | 375766803 | 5000000 | 0 | 100 | 0
结果提供有关活动加载状态的信息。如果要检查历史加载状态，请将WHERE子句更改为WHERE is_executing =‘f’。
监控锁定状态
Vertica使用锁来管理数据并发性和一致性。Vertica通过限制用户可以对对象执行的操作来自动控制锁定，具体取决于该对象的状态。Vertica使用锁来监视所有节点的锁授予和请求。没有结果的查询表明没有锁使用。
=> SELECT locks.lock_mode, locks.lock_scope, substr(locks.transaction_description, 1, 100) AS "left", locks.request_timestamp, locks.grant_timestamp FROM v_monitor.locks;
lock_mode | lock_scope | left | request_timestamp | grant_timestamp
----------+-------------+------------------------------------------------------------------------------------------------------+-------------------------------+------------------------------
I | TRANSACTION | Txn: a0000000003082 'COPY store.Store_Sales_Fact FROM '/opt/vertica/examples/VMart_Schema/Store_Sale | 2017-03-17 18:47:46.462589+09 | 2017-03-17 18:47:46.462594+09
(1 row)
锁系统表提供有关具有活动锁的事务的信息。此信息有助于分析批处理过程中的问题，并了解查询运行缓慢的原因。
恢复
监控节点恢复状态
在Vertica数据库中，处于DOWN状态的节点不参与自节点关闭以来提交的任何事务。重新启动DOWN节点后，该节点必须恢复从伙伴节点丢失的数据，然后再转到UP状态。当节点状态为RECOVERING时，使用恢复状态系统表跟踪节点的进度。
=> SELECT node_name，recover_epoch，recovery_phase，current_completed，current_total，is_running FROM v_monitor.recovery_status ORDER BY 1;
node_name | recover_epoch | recovery_phase | current_completed | current_total | is_running
----------------- + --------------- + --------------- - + ------------------- + --------------- + -----------
v_vmart_node0001 | | | 0 | 0 | f
v_vmart_node0002 | | | 0 | 0 | f
v_vmart_node0003 | | | 0 | 0 | f
不同的状态是：
- is_running-恢复正在运行
- current_completed - 完成恢复的projection数量
- current_total-应该恢复的projection数量
重新平衡
监控重新平衡状态
在Vertica群集中添加或删除节点后，Vertica会在节点之间重新分配数据以获得最佳性能。
=> SELECT GET_NODE_DEPENDENCIES();
GET_NODE_DEPENDENCIES
--------------------------------------------------------------
Deps:
00011 - cnt: 13
00110 - cnt: 13
01100 - cnt: 13
11000 - cnt: 13
10001 - cnt: 13
11111 - cnt: 27
一个干净的节点依赖列表（节点数+ 1）行。每行显示分段投影的数量，最后一行指定复制投影的数量。在二进制形式中，每个数字代表一个节点。例如，在二进制形式00011中，节点1 = 1，节点2 = 1，节点3 = 0，节点4 = 0，节点5 = 0. 1表示节点上存在段，0表示段表示节点上不存在。
监控再平衡运行的总体进展
使用以下查询监视每个当前正在执行的重新平衡操作的进度：
=> SELECT rebalance_method Rebalance_method, Status, COUNT(*) AS Count
FROM ( SELECT rebalance_method, CASE WHEN (separated_percent = 100 AND transferred_percent = 100) THEN 'Completed' WHEN ( separated_percent <> 0 and separated_percent <> 100) OR (transferred_percent <> 0 AND transferred_percent <> 100) THEN 'In Progress' ELSE 'Queued' END AS Status FROM v_monitor.rebalance_projection_status WHERE is_latest) AS tab GROUP BY 1, 2 ORDER BY 1, 2;
Rebalance_method | Status | Count
-----------------+-------------+-------
ELASTIC_CLUSTER | Completed | 8
ELASTIC_CLUSTER | In Progress | 2
ELASTIC_CLUSTER | Queued | 2
REPLICATE | Completed | 50
(4 rows)
查询监视每个当前正在执行的重新平衡操作的进度并返回：
- 用于重新平衡当前投影的方法。可能的值为REFRESH，REPLICATE和ELASTIC_CLUSTER
- 该方法的状态
- 投影数量
历史活动
根据执行时间监控查询
检查10个查询的执行时间，并获取有关慢查询的详细信息。
=> SELECT user_name, start_timestamp, request_duration_ms, transaction_id, statement_id, substr(request, 0, 1000) as request FROM v_monitor.query_requests WHERE transaction_id > 0 ORDER BY request_duration_ms DESC limit 10;
user_name | start_timestamp | request_duration_ms | transaction_id | statement_id | request
----------+-------------------------------+---------------------+-------------------+--------------+---------------------------------------------------------------------
dbadmin | 2017-03-30 12:33:56.381062-04 | 7567403 | 45035996274122533 | 1 | SELECT identifier, query FROM query_profiles;
dbadmin | 2017-03-23 13:17:45.350174-04 | 6993612 | 45035996274068604 | 2 | select counter_name from execution_engine_profiles;
dbadmin | 2017-03-13 13:17:12.618154-04 | 2195859 | 45035996273989990 | 2 | select * from customer_dimension;
dbadmin | 2017-03-23 15:14:44.586491-04 | 988246 | 45035996274068604 | 4 | select * from execution_engine_profiles;
dbadmin | 2017-04-13 10:08:21.999011-04 | 735847 | 45035996274232535 | 13 | SELECT * FROM v_monitor.system_resource_usage ORDER BY end_time DESC;
query_requests系统表返回有关用户发出的查询请求的信息。request_duration_ms列提供有关查询以毫秒为单位运行的时间长度的信息。根据这些结果，您可以识别需要很长时间才能执行的查询，并定位这些慢速查询以解决疑难解答问题。
监视内存使用情况
在Vertica数据库中，某些查询可能会使用更多内存，而其他查询可能会因数据量或查询复杂性而使用较少的内存。使用以下查询了解特定查询的内存使用情况：
=> SELECT node_name, transaction_id, statement_id, user_name, start_timestamp, request_duration_ms, memory_acquired_mb, substr(request, 1, 100) AS request FROM v_monitor.query_requests WHERE transaction_id = transaction_id AND statement_id = statement_id;
node_name | transaction_id | statement_id | user_name | start_timestamp | request_duration_ms | memory_acquired_mb | request
----------------+-------------------+--------------+-----------+-------------------------------+---------------------+--------------------+-------------------------------------------------------------------------------
v_demo_node0001 | 45035996273715536 | 1 | dbadmin | 2017-03-17 15:53:20.645486+09 | 19662 | 1838.12 | COPY mountains from '/home/dbadmin/data/flex/data.json' parser fjsonparser();
(1 row)
结果可帮助您了解每个查询的内存使用情况。根据结果，您可以改进查询。您可以更改表格或投影设计，也可以减少数据量。
对象统计
监视分区
通过节点分区，您可以轻松识别要删除的数据，并帮助回收磁盘空间。最初使用CREATE TABLE定义表时，可以为表指定分区，Vertica会在每次加载操作时自动分区数据。或者，您可以通过使用ALTER TABLE修改其定义来为现有表指定分区。您必须使用Vertica函数PARTITION_TABLE显式重新分区现有数据。ROS_COUNT字段的默认最大值为1024。使用以下查询查看每个投影的每个节点的分区计数：
=> SELECT node_name, projection_name, count(partition_key) FROM v_monitor.partitions GROUP BY node_name, projection_name ORDER BY node_name, projection_name;
node_name | projection_name | count
----------------+-----------------------------+-------
v_demo_node0001 | inventory_fact_partition_b0 | 5
v_demo_node0001 | inventory_fact_partition_b1 | 5
结果显示了分区的数量。如果投影的分区数量很大，则可以使用ALTER TABLE更改现有表的元数据。
监控分段和数据偏差
分段是指跨群集节点组织和分发数据，以实现快速数据清除和查询性能。分段旨在将数据均匀地分布在多个数据库节点上，以便所有节点都参与查询执行。您可以使用CREATE PROJECTION语句的哈希分段子句指定分段。但是，数据库可能会遇到数据偏差。使用以下查询查看每个节点的每个分段投影的行数：
=> SELECT ps.node_name，ps.projection_schema，ps.projection_name，ps.row_count FROM v_monitor.projection_storage ps
INNER JOIN v_catalog.projections p ON ps.projection_schema = p.projection_schema AND ps.projection_name = p.projection_name WHERE p.is_segmented ORDER BY ps.projection_schema，ps.projection_name，ps.node_name;
node_name | projection_schema | projection_name | row_count
---------------- + ------------------- + ------------ ------------ + ----------
v_demo_node0001 | online_sales | online_sales_fact_b0 | 5001927
v_demo_node0002 | online_sales | online_sales_fact_b0 | 4999302
v_demo_node0003 | online_sales | online_sales_fact_b0 | 4998771
使用上述结果监视数据偏斜。每个节点的投影应具有相同的行数，行计数的较大差异表示数据偏斜。您可以通过正确设计投影来最小化数据偏斜。
性能
监控查询性能
当您向Vertica提交查询以进行处理时，Vertica查询优化器会自动选择一组操作来计算请求的结果。这些操作一起称为查询计划。操作的选择可以极大地提高计算查询结果所需的运行时性能和资源消耗。根据数据库中定义的投影的属性，查询优化器可以选择更快，更有效的操作来计算查询结果。随着数据库的增长，查询会降低性能。监视查询的性能非常重要 - 尤其是经常运行的查询或访问大型数据集。query_events系统表返回有关查询计划，优化和执行事件的信息。
监控负载流
load_streams系统表包含有关负载流的活动和历史负载指标的数据。这对于获取有关从先前加载和拒绝的记录数的统计信息非常有用。Vertica维护系统表指标，直到达到指定的大小配额（以千字节为单位）。此配额是通过内部流程设置的，您无法直接设置或查看这些流程。使用以下查询查看加载流的性能：
=> SELECT schema_name, table_name, load_start, load_duration_ms, is_executing, parse_complete_percent, sort_complete_percent, accepted_row_count, rejected_row_count FROM v_monitor.load_streams;
schema_name | table_name | load_start | load_duration_ms | is_executing | parse_complete_percent | sort_complete_percent | accepted_row_count | rejected_row_count
-------------+-------------------+-------------------------------+------------------+--------------+------------------------+-----------------------+---------------------+------------------
myschema | table01 | 2017-02-13 15:48:49.983308-05 | 9283 | f | | 100 | 4 | 0
public | fruits | 2017-02-21 14:01:51.549974-05 | 343115 | f | | 100 | 4 | 0
store | store_orders_fact | 2017-02-06 10:55:24.073555-05 | 1513 | f | 100 | 100 | 300000 | 0
myschema | table01 | 2017-02-14 14:16:39.336496-05 | 7711 | f | | 100 | 3 | 0
public | casey1 | 2017-03-16 14:48:46.446581-04 | 15419 | f | | 100 | 3 | 0
online_sales | online_sales_fact | 2017-02-06 10:55:25.634915-05 | 17401 | f | 100 | 100 | 5000000 | 0
myschema | table01 | 2017-02-13 11:57:05.532119-05 | 15973 | f | | 100 | 5 | 0
类似资料：