Thread: миграция на PG с других СУБД
Приветствую! Подскажите пожалуйста, имеется ли у кого опыт миграции с других СУБД на 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@mail.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@mail.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@sai.msu.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@sai.msu.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 использует файловую структуру только для хранения данных, и каким-то образом оптимизирует/размещает данные в памяти, то получается что одни и теже данные кешируются дважды, что уже не оптимально. выбирая между кешированием данных субд и кешированием файлов ОС лучше предпочтение отдать первому. Или я где-то ошибся в расчетах? Поделитесь своими соображениями, не дайте умереть от безграмотности $) -- У каждого в башке свои тараканы...