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: миграция н  ("Viktor Vislobokov" <vvislobokov@parma-telecom.ru>)
Re: миграция н  (Oleg Bartunov <oleg@sai.msu.su>)
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:

Previous
From: Genix
Date:
Subject: вопрос по данной рассылке
Next
From: "Viktor Vislobokov"
Date:
Subject: Re: миграция н