Как получить последнюю дату доступа/изменения базы данных PostgreSQL?

На сервере разработки я хотел бы удалить неиспользуемые базы данных. Чтобы понять, что мне нужно знать, что база данных по-прежнему используется кем-то или нет.

Есть ли способ получить последний доступ или дату изменения данной базы данных, схемы или таблицы?

Ответы

Ответ 1

Вы можете сделать это, проверив время последней модификации файла таблицы. В postgresql каждая таблица соответствует одному или нескольким файлам os, например:

select relfilenode from pg_class where relname = 'test';

relfilenode - это имя файла таблицы "test". Затем вы можете найти файл в каталоге базы данных.

в моей тестовой среде:

cd /data/pgdata/base/18976

ls -l -t | head

Последняя команда означает перечисление всех файлов, упорядоченных по последнему времени модификации.

Ответ 2

Нет встроенного способа сделать это - и все подходы, которые проверяют файл mtime, описанный в других ответах, здесь неверны. Единственным надежным вариантом является добавление триггеров в каждую таблицу, которая записывает изменения в одну таблицу истории изменений, которая ужасно неэффективна и не может быть выполнена ретроактивно.

Если вы заботитесь только о том, что "используемая база данных" и "база данных не используется", вы можете собирать эту информацию из файлов журнала базы данных формата CSV. Обнаружение "измененных" и "не измененных" намного сложнее; рассмотрим SELECT writes_to_some_table(...).

Если вам не нужно обнаруживать старую активность, вы можете использовать pg_stat_database, который записывает активность со времени последней статистики reset. например:.

-[ RECORD 6 ]--+------------------------------
datid          | 51160
datname        | regress
numbackends    | 0
xact_commit    | 54224
xact_rollback  | 157
blks_read      | 2591
blks_hit       | 1592931
tup_returned   | 26658392
tup_fetched    | 327541
tup_inserted   | 1664
tup_updated    | 1371
tup_deleted    | 246
conflicts      | 0
temp_files     | 0
temp_bytes     | 0
deadlocks      | 0
blk_read_time  | 0
blk_write_time | 0
stats_reset    | 2013-12-13 18:51:26.650521+08

поэтому я вижу, что на этой БД была активность с последней статистики reset. Тем не менее, я ничего не знаю о том, что произошло до статистики reset, поэтому, если бы у меня была БД, показывающая нулевую активность со времени статистики reset полчаса назад, я бы ничего не знал.

Ответ 3

PostgreSQL 9.5 позволяет отслеживать последний измененный коммит.

  1. Проверьте, что фиксация трека включена или выключена с помощью следующего запроса

    show track_commit_timestamp;
    
  2. Если он возвращает "ON", перейдите к шагу 3, иначе измените postgresql.conf

    cd /etc/postgresql/9.5/main/
    vi postgresql.conf
    

    + Изменить

    track_commit_timestamp = off
    

    в

    track_commit_timestamp = on
    

    Перезапустите postgres/систему

    Повторите шаг 1.

  3. Используйте следующий запрос для отслеживания последнего коммита

    SELECT pg_xact_commit_timestamp(xmin), * FROM  YOUR_TABLE_NAME;
    
    SELECT pg_xact_commit_timestamp(xmin), * FROM YOUR_TABLE_NAME where COLUMN_NAME=VALUE;
    

Ответ 4

Мой способ получить дату изменения моих таблиц:

Функция Python

CREATE OR REPLACE FUNCTION py_get_file_modification_timestamp(afilename text)
  RETURNS timestamp without time zone AS
$BODY$
    import os
    import datetime
    return datetime.datetime.fromtimestamp(os.path.getmtime(afilename))
$BODY$
  LANGUAGE plpythonu VOLATILE
  COST 100;

SQL Query

SELECT
    schemaname,
    tablename,
    py_get_file_modification_timestamp('*postgresql_data_dir*/*tablespace_folder*/'||relfilenode)
FROM
    pg_class
INNER JOIN
    pg_catalog.pg_tables ON (tablename = relname)
WHERE
    schemaname = 'public'

Я не уверен, что такие вещи, как вакуум, могут испортить этот подход, но в моих тестах это довольно удобный способ получить таблицы, которые больше не используются, по крайней мере, в операциях INSERT/UPDATE.

Ответ 5

Я думаю, вы должны активировать некоторые параметры журнала. Вы можете получить информацию о регистрации на postgreSQL здесь.