Полезные запросы PostgreSQL

Написал admin . Опубликовано в Databases просмотров 494

Так себеПойдетХорошоПонравилосьОтличный пост (1 votes, average: 4,00 out of 5)
Загрузка...

1. Чем сейчас занимается SQL сервер?
select * from pg_stat_activity;
select * from pg_stat_database;

2. Как сбросить статистику (PostgreSQL 8.3)?
select pg_stat_reset();

Репликация LDAP (часть 1)

Написал admin . Опубликовано в Databases, Unix просмотров 570

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

Обзор

Репликация LDAP может пригодиться в тех случаях, когда необходимо иметь несколько идентичных копий директорий LDAP. К примеру клиенты директории LDAP географически распределены и локальные копии директории были бы более предпочтительны в плане скорости доступа. Репликацию можно настроить как на полное дерево, так и на отдельные ветки директории.

Стандартная модель репликации LDAP выглядит в виде иерархии, где есть один master сервер и несколько slave (еще их называют shadow) серверов.

Master сервер отвечает за поддержание slave серверов в актуальном состоянии. Все изменения в директории вносятся на нем и по средством репликации переносятся на slave.
Slave сервера предоставляют каталог для поиска пользователям. Все запросы на поиск обрабатывают они, а не master. Все slave сервера соответственно работают в режиме read-only и не позволяют вносить изменения в данные директории. Этим занимается только master сервер. В случае попытки сделать на slave сервере операцию изменения данных (удаление, изменение или добавление записи), он вернет клиенту ссылку (refferal) на master сервер. Клиент при получении такой ссылки, будет обязан повторно выполнить операцию на предложенном master сервере.

Отмена запущенных запросов в pgsql

Написал admin . Опубликовано в Databases просмотров 625

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

Для отмены запущеных запросов в pgsql можно воспользоваться системными SP. К примеру отменить множественные инсерты или множество продолжительных запросов:
SELECT pg_cancel_backend(procpid) as x
FROM  pg_stat_activity
WHERE current_query like 'INSERT%';

Размеры объектов БД PostgreSQL

Написал admin . Опубликовано в Databases просмотров 1 513

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

Все объекты БД в PostgreSQL хранятся в каталоге data/base в виде OID (таблицы, индексы…).
Для сопоставления OID номеров с именами баз и таблиц в contrib есть утилита oid2name (перед использованием скомпилить и положить в удобное для использования место).

Для просмотра размера всех таблиц текущей БД можно использовать такой запрос:

SELECT relname AS name, relfilenode AS oid, (relpages * 8192 / (1024*1024))::int as size_mb, reltuples as count FROM pg_class WHERE relname NOT LIKE 'pg%' ORDER BY relpages DESC;

PostgreSQL — формула оптимизации

Написал admin . Опубликовано в Databases просмотров 1 996

Так себеПойдетХорошоПонравилосьОтличный пост (1 votes, average: 5,00 out of 5)
Загрузка...

Среднестатистическая настройка для максимальной производительности.

RAM — объем памяти сервера

shared_buffers = 1/8 RAM или больше (но не более 1/4);
work_mem в 1/20 RAM;
maintenance_work_mem в 1/4;
max_fsm_relations в планируемое кол-во таблиц в базах * 1.5;
max_fsm_pages в max_fsm_relations * 2000;
fsync = true;
wal_sync_method = fdatasync;
commit_delay = от 10 до 100 ;
commit_siblings = от 5 до 10;
effective_cache_size = 0.9 от значения cached, которое показывает free;
random_page_cost = 2 для быстрых cpu, 4 для медленных;
cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;
cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;

Восстановление PostgreSQL после повреждения файлов XLOG

Написал admin . Опубликовано в Databases просмотров 6 182

Так себеПойдетХорошоПонравилосьОтличный пост (6 votes, average: 4,67 out of 5)
Загрузка...

Бывают случаи, когда файлы журнала транзакций (pg_xlog) могут быть повреждены или случайно удалены. В таком случае PGSQL не сможет работать и просто не запустится с подобной ошибкой:

Jul 4 11:30:18 database postgres[92997]: [1-1] LOG: database system was interrupted at 2009-07-04 11:24:30 MSD
Jul 4 11:30:18 database postgres[92997]: [2-1] LOG: could not open file "pg_xlog/000000010000031A00000027" (log file 794, segment 39): No such file or directory
Jul 4 11:30:18 database postgres[92997]: [3-1] LOG: invalid primary checkpoint record
Jul 4 11:30:18 database postgres[92997]: [4-1] LOG: could not open file "pg_xlog/000000010000031A00000026" (log file 794, segment 38): No such file or directory
Jul 4 11:30:18 database postgres[92997]: [5-1] LOG: invalid secondary checkpoint record
Jul 4 11:30:18 database postgres[92997]: [6-1] PANIC: could not locate a valid checkpoint record

Найти поврежденный xlog-файл вряд ли получится, поэтому выход один — очистить информацию в БД об используемых логах. Для этого есть штатная утилита pg_resetxlog

PostgreSQL: аналитика для DBA

Написал admin . Опубликовано в Databases просмотров 362

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

Многие пользователи СУБД PostgreSQL знают, что сервер во время своей работы собирает разнообразную статистику, но не все знают, что ее полезно анализировать и как ее извлекать для этого. В этом небольшом тулките собраны несколько полезных запросов, дающих некоторое представление о том, как использовать это «скрытое знание», которое постоянно копится. Эти запросы можно использовать для мониторинга состояния PostgreSQL (ручного или с помощью плагинов для систем мониторинга вроде Nagios, Cacti или Zabbix), для поиска узких мест в работе сервера и многих других подобных задач. Помните, что это лишь верхушка айсберга; в документации можно найти описания нескольких десятков системных представлений, которые также могут быть полезны администратору PostgreSQL.

Для корректной работы тулкита необходимо включить опции stats_block_level и stats_row_level в postgresql.conf, а также настроить параметр stats_reset_on_server_start по своему усмотрению. Если при каждом перезапуске сервера PostgreSQL вы меняете какие-то существенные параметры его конфигурации, имеет смысл обнулять статистику, чтобы отслеживать эффект внесенных изменений. Если же вас интересует долгосрочная перспектива и рестарт производится не вследствие изменения конфигурации PostgreSQL, ставьте параметр stats_reset_on_server_start в значение off.