问题[monitoring](dba)

因此，我在 docker 中构建了带有 citus 扩展的 PostgreSQL。我在 citus 中使用官方文档，然后在终端中运行此命令。

docker run -d -v /root/volumes/citus-data:/data  --network citus-network --name citus_coordinator -p 5500:5432 -e POSTGRES_PASSWORD=mypassword citusdata/citus:11.1

然后数据库成功构建。但我想创建pg_stat_statements扩展。我配置 postgresql.conf文件。

shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all
pg_stat_statements.max = 10000
track_activity_query_size = 2048

然后我重新启动了 PostgreSQL 容器。写了这个查询

SELECT * FROM pg_stat_statements;

在终端。我看到了这个错误

[55000] ERROR: pg_stat_statements must be loaded via shared_preload_libraries

我不明白，为什么配置文件没有看到这个扩展名，我的错误是什么？

解决 了我正在使用 postgres:latest image 运行 PostgreSQL 容器。然后我进入了容器。所以，我将 citus 从这里安装到容器中。然后安装apt-get install postgresql-contrib到容器中。下一步，运行create extension pg_stat_statements; 一切对我有用。

是否有监控的经验法则mysql.innodb.buffer_pool_reads / mysql.innodb.buffer_pool_read_requests？

我正在使用以下公式，但我开始认为它太敏感了。

(mysql.innodb.buffer_pool_reads / mysql.innodb.buffer_pool_read_requests) * 100 > 0.2

如何使用 pg_isready 监控特定数据库？

实例：DBSPG10T1 版本：10.14 端口：62​​41

postgres@postgres # SELECT datname FROM pg_database;
  datname
-----------
 postgres
 template1
 template0
 dbspg10t1

[postgres@HOSTNAME ~]$ if pg_isready -d postgres://localhost:6241/dbspg10t1; then echo "200 OK"; else echo "500 NOT OK"; fi
localhost:6241 - accepting connections
200 OK

数据库测试不存在，但 pg_isready 仍然返回 ok。

[postgres@HOSTNAME ~]$ if pg_isready -d postgres://localhost:6241/test; then echo "200 OK"; else echo "500 NOT OK"; fi
localhost:6241 - accepting connections
200 OK

这是语法问题吗？

我对数据库相当陌生，我有一个特定的要求来编写作业/存储过程来监控数据库的增长。

我们目前正在使用MS SQL Server 2016 Standard Editionwith Always-ON HA。

我已经mail server在数据库上设置了。
将作业的输出链接到邮件会更有效。

我一直在使用以下命令在 HP-UX（Itanium）上的 Sybase ASE 15.7（SP139）上运行系统监视器（sysmon）：

sp_sysmon "00:10:00"
go

观察到插入次数在一天中的任何时间都非常高，无法找到它的来源和详细信息，例如表名、数据库名、程序名等。下面是清晨 sysmon 的示例输出，当时有空载：

Transaction Profile
-------------------

  Transaction Summary             per sec      per xact       count  % of total
  -------------------------  ------------  ------------  ----------  ---------- 
    Committed Xacts                  10.7           n/a        6390     n/a     

  Transaction Detail              per sec      per xact       count  % of total
  -------------------------  ------------  ------------  ----------  ---------- 
  Inserts
    Fully Logged
      APL Heap Table              58665.7        5508.5    35199448     100.0 %
      APL Clustered Table             0.0           0.0           7       0.0 %
      Data Only Lock Table           13.2           1.2        7918       0.0 %
      Fast Bulk Insert                0.0           0.0           0       0.0 %
      Fast Log Bulk Insert            0.0           0.0           0       0.0 %
    Minimally Logged
      APL Heap Table                  0.0           0.0           0       0.0 %
      APL Clustered Table             0.0           0.0           0       0.0 %
      Data Only Lock Table            0.0           0.0           0       0.0 %
  -------------------------  ------------  ------------  ----------  ---------- 
  Total Rows Inserted             58679.0        5509.8    35207373     100.0 %

看起来 tempdb 中正在发生插入，但是这么多插入有点麻烦，感谢专家的建议。

运行社区 8.0.14 的服务器，几天前我们达到了打开文件的数量，所以我增加了限制，但过了一会儿服务器在错误日志中崩溃了：

InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
03:07:21 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=221
max_threads=1000
thread_count=4
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 403301 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f9200000b20
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7fd571ceaca0 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char*, unsigned long)+0x3d) [0x561bdb69757d]
/usr/sbin/mysqld(handle_fatal_signal+0x423) [0x561bda8277c3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890) [0x7fe5095f6890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7) [0x7fe507981e97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141) [0x7fe507983801]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x2d5) [0x561bdb94d2c5]
/usr/sbin/mysqld(+0x1fe243c) [0x561bdb94f43c]
/usr/sbin/mysqld(mem_heap_create_block_func(mem_block_info_t*, unsigned long, unsigned long)+0x9ba) [0x561bdb95638a]
/usr/sbin/mysqld(mem_heap_add_block(mem_block_info_t*, unsigned long)+0x72) [0x561bdb956562]
/usr/sbin/mysqld(trx_undo_update_rec_get_update(unsigned char const*, dict_index_t*, unsigned long, unsigned long, unsigned long, unsigned long, trx_t*, mem_block_info_t*, upd_t**, lob::undo_vers_t*, type_cmpl_t&)+0x1926) [0x561bdb924896]
/usr/sbin/mysqld(row_purge_step(que_thr_t*)+0x845) [0x561bdb8b7ad5]
/usr/sbin/mysqld(que_run_threads(que_thr_t*)+0x997) [0x561bdb859597]
/usr/sbin/mysqld(srv_worker_thread()+0x29d) [0x561bdb8e85bd]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Runnable, void (*)()> > >::_M_run()+0x63) [0x561bdb759883]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xbd57f) [0x7fe5083a757f]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7fe5095eb6db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7fe507a6488f]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 0
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
2019-01-27T03:07:37.554520Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.14) starting as process 56489

InnoDB: Progress in percents: 1InnoDB MEMCACHED: Memcached uses atomic increment
 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 1002019-01-27T03:12:07.973920Z 0 [System] [MY-010229] [Server] Starting crash recovery...
2019-01-27T03:12:07.982255Z 0 [System] [MY-010232] [Server] Crash recovery finished.
2019-01-27T03:12:10.581437Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2

机器是 2x Xeon E5-2680v4 - 28c/56t - 2.4GHz /3.3GHz，512GB RAM，配置文件：

server-id = 1
log-bin   = /var/lib/mysql-binlogs/web07
relay-log = web07-relay-bin

binlog_expire_logs_seconds = 259200

open_files_limit = 10000
max_connections = 1000

innodb_flush_method=O_DIRECT
innodb_flush_log_at_trx_commit=0
innodb_log_file_size=38G

innodb_buffer_pool_size=300G
innodb_buffer_pool_instances=64

join_buffer_size=5M
tmp_table_size=1G
max_heap_table_size=512M
skip_name_resolve=1

table_open_cache=20000

sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION,NO_AUTO_VALUE_ON_ZERO"

relay-log-recovery=1

default-authentication-plugin=mysql_native_password

在那次崩溃之后，如果我在打开的文件太多（大约每 24 小时一次）时不重新启动它，服务器会再次崩溃，例如：

$ mysql -e "show global status like 'open_%';"
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Open_files               | 62507 |
| Open_streams             | 0     |
| Open_table_definitions   | 1843  |
| Open_tables              | 18779 |
| Opened_files             | 71902 |
| Opened_table_definitions | 3168  |
| Opened_tables            | 18803 |
+--------------------------+-------+

当我写这个问题时，服务器崩溃了：

2019-01-29T22:27:51.031406Z 54298197 [ERROR] [MY-013132] [Server] The table '/tmp/#sql9ae8_33c8655_13' is full!

2019-01-29T22:28:01.844610Z 54321796 [ERROR] [MY-013132] [Server] The table '/tmp/#sql9ae8_33ce284_1' is full!

如何调试为什么有这么多打开的文件？流量很大，但通常打开的连接不超过 10 个，为什么临时表没有关闭？

lsof：（~27k 总行，重启后 10 小时）

COMMAND   PID  USER   FD      TYPE             DEVICE     SIZE/OFF       NODE NAME
mysqld  23964 mysql  cwd       DIR                9,3         4096   49549201 /var/lib/mysql
mysqld  23964 mysql  rtd       DIR                9,3         4096          2 /
mysqld  23964 mysql  txt       REG                9,3     56952368    6292097 /usr/sbin/mysqld
mysqld  23964 mysql  DEL       REG                9,3                12858561 /tmp/mysql_temptable.As3HWG
mysqld  23964 mysql  DEL       REG                9,3                12858557 /tmp/mysql_temptable.I4gP0F
mysqld  23964 mysql  DEL       REG                9,3                12858554 /tmp/mysql_temptable.W139aF
mysqld  23964 mysql  DEL       REG                9,3                12858553 /tmp/mysql_temptable.MhBwlE
mysqld  23964 mysql  DEL       REG                9,3                12858551 /tmp/mysql_temptable.mcw0vD
mysqld  23964 mysql  DEL       REG                9,3                12858550 /tmp/mysql_temptable.OFuZ94
mysqld  23964 mysql  DEL       REG                9,3                12858544 /tmp/mysql_temptable.2ffRvY
mysqld  23964 mysql  DEL       REG                9,3                12858549 /tmp/mysql_temptable.VvXQPw
mysqld  23964 mysql  DEL       REG                9,3                12858541 /tmp/mysql_temptable.KTTZRR
mysqld  23964 mysql  DEL       REG                9,3                12858542 /tmp/mysql_temptable.eMVSbq
mysqld  23964 mysql  DEL       REG                9,3                12858538 /tmp/mysql_temptable.6Kaay

在第一行之后，所有文件都被（删除）。我认为这是问题所在，为什么没有发布这些指针？

mysqld  27864 mysql 1658u      REG                9,3      1048584   12846342 /tmp/mysql_temptable.wazlKx (deleted)
mysqld  27864 mysql 1660u      REG                9,3      1048584   12846352 /tmp/mysql_temptable.S5Oo1m (deleted)
mysqld  27864 mysql 1662u      REG                9,3      1048584   12846343 /tmp/mysql_temptable.l1CZjK (deleted)
mysqld  27864 mysql 1666u      REG                9,3      1048584   12846366 /tmp/mysql_temptable.VDaTxb (deleted)

2019-02-19：我按照建议增加了一些限制，并做了一个mysqlcheck --all-databases，没有任何变化。

正如评论中所写，即使我停止流量，打开文件的数量也不会减少。

该应用程序被证明是稳定的，并且在问题出现之前的几天内，代码或流量没有发生重大变化。（我 100% 确定，因为那天是假期，主分支上没有提交）

我们在周末的晚上有一个有问题的时间窗口。我想设置多个扩展事件会话来捕获一些数据并获得洞察力。

他们中的大多数将针对一个文件，我可以稍后阅读，但我的问题是直方图。

我可以配置一个作业来改变 XE 会话在特定时间开始，但我不能停止会话，因为它会从内存中删除直方图数据。

AFAIK 在运行时，我无法将直方图结果从内存保存到磁盘。

如果我在实际事件上设置时间戳谓词（尚未测试）并让 XE 会话在周末运行并在周一读取结果，也许有一种方法可以只捕获直方图中的数据。

还有其他方法可以仅在特定时间窗口内捕获直方图结果吗？

我们正在使用 SentryOne 监控服务器并注意到一些非常奇怪的事情。当查看相同服务器数据但 SentryOne 软件在不同时区运行时，数据似乎发生了偏移且不同步。我想知道这是否是由于某处的某些设置造成的，但找不到任何东西。任何人都知道如何解决这个问题......或者这是一个错误？

我正在研究 SQL Server 系统视图和 Windows 性能计数器，但找不到任何关于给定数据库中每个表的查询量的指标。我正在寻找任何类型的信息来衡量给定数据库中每个表的有用性。查询计数/行计数/查询结果的数据大小，或任何类似的东西都会很棒。有没有人对如何查看每个表的数据有建议？我可以随着时间的推移执行 Profiler 跟踪或 XE 会话，然后查询这些结果以进行一些分组，但如果数据已经存在于某处，则不希望增加开销。

我对 Oracle 数据库了解不多，使用了这里的一些问题来获取此查询：

select case when ((sysdate - timestamp)*24 < 1 and returncode <> 0) then 

(username  || '@' || userhost|| ' ON ' || to_char(timestamp,'DD-MON-YYYY HH24:MI:SS')|| ' FAILED AT ' || action_name || ' BECAUSE ' || returncode || decode(returncode,'28000',':Maximum Login Attempt','1004',':Wrong Connection','1005',':NULL Password','1017',':Wrong Password','1045',':Insufficient Priviledge','0',':Login Accepted',':Unkown Code')) 

else 'none' 

end as "locked users" from sys.dba_audit_session where (sysdate - timestamp)*24 < 1 and returncode <> 0 order by timestamp;

通过此查询，我想检索在哪个日期锁定的用户以及导致锁定的原因，如果没有用户，则仅返回“无”而不是“未选择行”。对于锁定的用户，它有效，但 else 语句无效。有人可以向我解释为什么吗？我需要这个来用 ODBC 修复我的 zabbix 数据库监控。