Re: миграция н - Mailing list pgsql-ru-general
From | Genix |
---|---|
Subject | Re: миграция н |
Date | |
Msg-id | 42512639.8010605@list.ru Whole thread Raw |
In response to | миграция на PG с других СУБД (Genix <genix@list.ru>) |
Responses |
Re: миграция н
Re: миграция н |
List | pgsql-ru-general |
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 вести онлайновый лог операций? т.е. писать все в какой-либо журнал по мере совершения действий на сервере. ну или хотя бы (что даже еще лучше) писать в журнал разницу между последними изменениями относительно какой-либо стадии логирования? насколько эффективны встроенные средства бекапа? -- У каждого в башке свои тараканы...
pgsql-ru-general by date: