Re: миграция н

From: Genix <genix(at)list(dot)ru>
To: vvislobokov(at)lukoilperm(dot)ru, pgsql-ru-general <pgsql-ru-general(at)postgresql(dot)org>
Subject: Re: миграция н
Date: 2005-04-04 11:34:17
Message-ID: 42512639.8010605@list.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 вести онлайновый лог операций? т.е. писать все в какой-либо
журнал по мере совершения действий на сервере. ну или хотя бы (что даже
еще лучше) писать в журнал разницу между последними изменениями
относительно какой-либо стадии логирования?

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

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

In response to

Responses

Browse pgsql-ru-general by date

  From Date Subject
Next Message Viktor Vislobokov 2005-04-04 11:41:54 Re: миграция н
Previous Message Genix 2005-04-04 10:53:51 вопрос по данной рассылке