Re: миграция н

Приветствую!

Подскажите пожалуйста, имеется ли у кого опыт миграции с других СУБД на
PostgreSQL? В частности интересует перенос баз данных с СУБД Informix.
На informix'е есть небольшое количество самописных SPL-процедур.
Может имеется задокументированный опыт или success story по такому
переходу опубликованная в интернете?

Как думает общественность, имеет смысл осуществлять данный переход?

--
У каждого в башке свои тараканы...

У меня опыта миграции нет, но как мне кажется, сложность миграции в
основном зависит от сложности самой базы.
Если база выполнена по стандарту SQL и никаких специфических наворотов
не содержит, то миграция не должна вызвать проблемы.
Сложности пожалуй могут быть только с процедурами, но и они решаемы.
Ну и по второму вопросу - однозначно стоит. Насколько я знаю Informix
больше не разрабатывается. Идёт только устранение багов по поддержке.
Так что имеет смысл подумать над переходом на другую СУБД.

> Приветствую!
>
> Подскажите пожалуйста, имеется ли у кого опыт миграции с других СУБД
> на PostgreSQL? В частности интересует перенос баз данных с СУБД
> Informix. На informix'е есть небольшое количество самописных
> SPL-процедур.
> Может имеется задокументированный опыт или success story по такому
> переходу опубликованная в интернете?
>
> Как думает общественность, имеет смысл осуществлять данный переход?
>

--
С уважением, Виктор

Viktor Vislobokov wrote:
> У меня опыта миграции нет, но как мне кажется, сложность миграции в
> основном зависит от сложности самой базы.
> Если база выполнена по стандарту SQL и никаких специфических наворотов
> не содержит, то миграция не должна вызвать проблемы.
> Сложности пожалуй могут быть только с процедурами, но и они решаемы.
> Ну и по второму вопросу - однозначно стоит. Насколько я знаю Informix
> больше не разрабатывается. Идёт только устранение багов по поддержке.
> Так что имеет смысл подумать над переходом на другую СУБД.

Информикс выпустил недавно совсем новую версию (10-ую) своей СУБД, но
это вопрос не решает.
Подскажите, какие есть инструменты мониторинга активности сессий в
postgre? Программистам хочется видеть план их запросов и отслеживать
скорость выполнения каждой составляющей этого плана. Есть ли что-нибудь
похожее для PostgreSQL?

Или ткните ссылкой, где можно почитать.

--
У каждого в башке свои тараканы...

> Подскажите, какие есть инструменты мониторинга активности сессий в
> postgre? Программистам хочется видеть план их запросов и

Насколько я знаю, мониторить активность сессий нельзя, т.е. что-то типа
onstat -su в Informix'е отсутствует.
С каких компов есть соединения можно понять только netstat'ом и наверное
всё.

> отслеживать скорость выполнения каждой составляющей этого плана. Есть
> ли что-нибудь похожее для PostgreSQL?
>
> Или ткните ссылкой, где можно почитать.
>
Про планы запросов и прочие вещи можно почитать здесь (смотрите нужные
разделы)
http://www.linuxshare.ru/postgresql/manual/index.html

--
С уважением, Виктор

Hello,

G> Или ткните ссылкой, где можно почитать.

http://www.postgresql.org/docs/8.0/static/index.html

Справка написана очень грамотно, понятно, хорошо структурирована
и содержит ответы практически на все возникающие вопросы. (на твой
вопрос точно есть :) )

Если нет - см. Faq
http://www.postgresql.org/docs/faq/
(там есть ссылка и на русский перевод).

--
Best regards,
Ivan mailto:Ivan-Sun1(at)mail(dot)ru

Viktor Vislobokov wrote:

> что-то типа onstat -su в Informix'е отсутствует.

приятно общаться с человеком, который знаком с обеими сторонами вопроса!

Еще вопрос, от informix'а осталась привычка (?) создавать raw-разделы на
дисковом массиве. Поддерживает ли работу с raw разделами pg_sql и имеет
ли смысл с ними связываться? (ускорение работы, как я полагаю)

--
У каждого в башке свои тараканы...

Viktor Vislobokov wrote:

не против, если я вернусь в русло рассылки, из которой случайно вылетел?

>> Еще вопрос, от informix'а осталась привычка (?) создавать raw-разделы
>> на дисковом массиве. Поддерживает ли работу с raw разделами pg_sql и
>> имеет ли смысл с ними связываться? (ускорение работы, как я полагаю)
>>
> Насколько мне известно не поддерживает. Но и смысла с ними связываться
> тоже не вижу.
> У PostgreSQL есть каталог с базами, где для каждой базы хранится набор
> файлов. Этот набор файлов обслуживается СУБД автоматически и также
> автоматически отслеживаются максимальные размеры файлов для файловой
> системы, т.е. никаких проблем, связанных с 2Gb на файл (или как в
> Informix'е было до версии <=9.30 на чанк) не существует.
>
> Не знаю насколько интересно будет такой маленький обзорчик:

Конечно интересен.

> - dbaccess нету, есть psql, который несколько на мой взгляд приятней
> (хотя на вкус и цвет). Что дико нравится - это возможность в psql
> получить помощь по SQL, набрав \h <SQL команда>
> - onmonitor не требуется
> - onstat нету, потому что того скопища информации, которую оно может
> предоставить в PostgreSQL нету (и не нужно помоему ;)
> - oncheck нету, потому что считается, что база и так должна быть
> консистентной
> - аналог dbexport - команда pg_dump. Аналог dbimport - команда psql <
> файл_дампа.
> - логи ведутся либо в syslog либо в отдельный файл - настраивается как и
> многое другое (включая настройки произодительности) в postgresql.conf (у
> меня он находится в /var/lib/pgsql/data). Доступ к базам настраивается в
> pg_hba.conf в этом же каталоге.

я имел некий опыт общения с базой, который к сожалению закончился
созданием одной-двух табличек с поиощью psql. т.е. ничего серьезного.

> - Вместо UPDATE STATISTICS в Informix, здесь есть свои команды VACUUM.

сейчас у меня update statistics делается раз в день (ночью). Как частно
необходимо делать vacuum для pg?
что скажет общественность про восстановление данных рухнувших баз? что
есть для этого в pg? как выглядит сам процесс восстановления (интересует
практический опыт, а не бумажная теория).

умеет ли pg вести онлайновый лог операций? т.е. писать все в какой-либо
журнал по мере совершения действий на сервере. ну или хотя бы (что даже
еще лучше) писать в журнал разницу между последними изменениями
относительно какой-либо стадии логирования?

насколько эффективны встроенные средства бекапа?

--
У каждого в башке свои тараканы...

На что-то отвечу, на что-то нет:

>
>> - Вместо UPDATE STATISTICS в Informix, здесь есть свои команды VACUUM.
>
>
> сейчас у меня update statistics делается раз в день (ночью). Как
> частно необходимо делать vacuum для pg?

Точно такие же сообращения как и для UPDATE STATISTICS.

> что скажет общественность про восстановление данных рухнувших баз? что
> есть для этого в pg? как выглядит сам процесс восстановления
> (интересует практический опыт, а не бумажная теория).

Если база рухнула и нету бакапа, то хрен его знает как это чинить. Тут
только теоретические есть соображения.

>
> умеет ли pg вести онлайновый лог операций? т.е. писать все в
> какой-либо журнал по мере совершения действий на сервере. ну или хотя
> бы (что даже еще лучше) писать в журнал разницу между последними
> изменениями относительно какой-либо стадии логирования?

Есть WAL - write-ahead logs. Помоему - это то о чём ты и говоришь

> насколько эффективны встроенные средства бекапа?
>
Бакап делается через pg_dump (для базы) или pg_dumpall (для всех баз).
Бакап получается в виде текстового файла с операторами SQL,
так что всё очень переносимо и надёжно и даже возможна правка.
Разумеется, что никто не мешает перенаправить стандартный вывод из
pg_dump в gzip или даже bzip2 и получить сжатый бакап базы.

Восстановление - это накат дампа + WAL.

--
С уважением, Виктор

Viktor Vislobokov wrote:

>> Еще вопрос, от informix'а осталась привычка (?) создавать raw-разделы
>> на дисковом массиве. Поддерживает ли работу с raw разделами pg_sql и
>> имеет ли смысл с ними связываться? (ускорение работы, как я полагаю)
>>
> Насколько мне известно не поддерживает. Но и смысла с ними связываться
> тоже не вижу.

а как тогда обходятся/запрещаются попытки ОС кешировать файлы, в которых
располагаются данные?

--
У каждого в башке свои тараканы...

Hello всем,

> что-то типа onstat -su в Informix'е отсутствует.

Я не знаком с информикс, но некоторую информацию Вы можете получить и
в Postgres'е:

Chapter 23. Monitoring Database Activity
http://www.postgresql.org/docs/8.0/static/monitoring.html

--
Best regards,
Ivan mailto:Ivan-Sun1(at)mail(dot)ru

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-1450712544-1112623723=:15865
Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 4 Apr 2005, Genix wrote:

> я имел некий опыт общения с базой, который к сожалению закончился созданием
> одной-двух табличек с поиощью psql. т.е. ничего серьезного.
>
>> - Вместо UPDATE STATISTICS в Informix, здесь есть свои команды VACUUM.
>
> сейчас у меня update statistics делается раз в день (ночью). Как частно
> необходимо делать vacuum для pg?

аналогично часто, так как суть у них абсолютно одинаковая, разве что
я бы порекомендовал поначалу 'vacuum verbose' поделать, чтобы параметры
подобрать в postgresql.conf правильные. Есть, кстати, autovacuum,
который в фоне ваукуумит те таблицы, которые этого требуют.
смотри contrib/pg_autovacuum

> что скажет общественность про восстановление данных рухнувших баз? что есть
> для этого в pg? как выглядит сам процесс восстановления (интересует
> практический опыт, а не бумажная теория).

нормально, если сохранент WAL

>
> умеет ли pg вести онлайновый лог операций? т.е. писать все в какой-либо
> журнал по мере совершения действий на сервере. ну или хотя бы (что даже еще
> лучше) писать в журнал разницу между последними изменениями относительно
> какой-либо стадии логирования?

WAL (write ahead log) все как по теории, аналогично и в информиксе.
Все думаю, что надо бы написать по-русски как транзакции в postgresql
устроены, да все некогда. Но могу заверить, что очень даже хорошо.

>
> насколько эффективны встроенные средства бекапа?
>

После PITR все пучком. Читайте доки, а лучше разбирайтесь и пишите ее :)
Есть мелочи, но практически не очень важные.

>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---559023410-1450712544-1112623723=:15865--

Viktor Vislobokov wrote:
>
>> Подскажите, какие есть инструменты мониторинга активности сессий в
>> postgre? Программистам хочется видеть план их запросов и
>
>
> Насколько я знаю, мониторить активность сессий нельзя, т.е. что-то типа
> onstat -su в Informix'е отсутствует.
> С каких компов есть соединения можно понять только netstat'ом и наверное
> всё.

select * from pg_stat_activity;

IP-адрес клиента в это представление обещали добавить.

--

С уважением,
технический директор ООО "ЦСА"
Николай Газалов
www.sbin.org
+7 8793 365584
(GPG Key ID: 4396B2D0)

>> Насколько я знаю, мониторить активность сессий нельзя, т.е. что-то
>> типа onstat -su в Informix'е отсутствует.
>> С каких компов есть соединения можно понять только netstat'ом и
>> наверное всё.
>
>
> select * from pg_stat_activity;
>
> IP-адрес клиента в это представление обещали добавить.
>
К сожалению пока не добавлено, а кроме того onstat в Infomix'е даёт ещё
и такую полезную
информацию как число прочитанных/записанных строк. Таким образом если
запускать
onstat с неким интервалом, становится понятно делает ли что-то клиент
или просто
держит открытым соединение.

--
С уважением, Виктор

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-2009100027-1112674848=:15865
Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 5 Apr 2005, Viktor Vislobokov wrote:

>
>>> Насколько я знаю, мониторить активность сессий нельзя, т.е. что-то типа
>>> onstat -su в Informix'е отсутствует.
>>> С каких компов есть соединения можно понять только netstat'ом и наверное
>>> всё.
>>
>>
>> select * from pg_stat_activity;
>>
>> IP-адрес клиента в это представление обещали добавить.
>>
> К сожалению пока не добавлено, а кроме того onstat в Infomix'е даёт ещё и
> такую полезную
> информацию как число прочитанных/записанных строк. Таким образом если
> запускать
> onstat с неким интервалом, становится понятно делает ли что-то клиент или
> просто
> держит открытым соединение.

select из pg_stat* тоже дает IO статистику.

>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---559023410-2009100027-1112674848=:15865--

>>> Еще вопрос, от informix'а осталась привычка (?) создавать
>>> raw-разделы на дисковом массиве. Поддерживает ли работу с raw
>>> разделами pg_sql и имеет ли смысл с ними связываться? (ускорение
>>> работы, как я полагаю)
>>>
>> Насколько мне известно не поддерживает. Но и смысла с ними
>> связываться тоже не вижу.
>
>
> а как тогда обходятся/запрещаются попытки ОС кешировать файлы, в
> которых располагаются данные?
>
А нехай кэширует. Для чтение файлов таблиц кэширование - это скорее
благо. А кэш записи в рамках
завершения транзакции сбрасывается на диск через системный вызов sync.

--
С уважением, Виктор

Viktor Vislobokov wrote:

>> а как тогда обходятся/запрещаются попытки ОС кешировать файлы, в
>> которых располагаются данные?
>>
> А нехай кэширует. Для чтение файлов таблиц кэширование - это скорее
> благо. А кэш записи в рамках
> завершения транзакции сбрасывается на диск через системный вызов sync.

если используется _только_ системный кэш, то возможно да.
если pg использует файловую структуру только для хранения данных, и
каким-то образом оптимизирует/размещает данные в памяти, то получается
что одни и теже данные кешируются дважды, что уже не оптимально.
выбирая между кешированием данных субд и кешированием файлов ОС лучше
предпочтение отдать первому.

Или я где-то ошибся в расчетах? Поделитесь своими соображениями, не
дайте умереть от безграмотности $)

--
У каждого в башке свои тараканы...