Резервирование БД Pervasive 8 в реальном времени

[Rambler]

Добрый день всем,

может кто поделиться опытом решения следующей задачки: очень хочется уметь резервировать в реальном (или с небольшой задержкой) времени СУБД Pervasive 8.0, на которой крутится RS-Bank 5.0 -- на случай экстренного восстановления при полной катастрофе системы. Чтобы если крах наступит -- восстанавливать ручками все транзакции/проводки не с вечера прошлого дня, а максимум за 5-10-15 минут до момента сбоя.

Кто-нибудь решал подобные задачи? Что можете посоветовать? Такая задача вообще решается за разумные цену/время? Идеологию можете подсказать?

[Vlad.S]

давно это было, но кажется так:
1. фиксируется состояние (до отмены изменения пишутся не в таблицы)
2. копируются файлы измененные с последнего времени копирования на другой сервер
3. разрешается запись в "основные таблицы"

может и наврал, но в любом случае но в доке к первасиву было все очень подробно расписано, посмотрите ее

[Samuel]

Была такая штука Pervasive Data Exchange. Я как то пробовал ее. В отделе поддержки должна была дока сохраниться... Попросите, может дадут.

[Big_Mike]

To Rambler
А реплицировать директории не пробовали?

[dd]

Big_Mike средствами чего? разверни

[Big_Mike]

dd Положим, штатными средствами Виндов.

[dd]

Big_Mike а если файл открыт, транзакции идут - то как? прокатит?
или имеется в виду просто "зеркало", т.е. рэйд1

[klinkin]

Big_Mike а если файл открыт, транзакции идут - то как? прокатит?
или имеется в виду просто "зеркало", т.е. рэйд1

Вопрос:
Есть ли средства, позволяющие производить архивирование или резервное копирование базы данных АБС RS-Bank, не прерывая работы пользователей?
Ответ:

Описанная возможность доступна пользователям Pervasive SQL 2000 и выше.
Для того чтобы провести резервное копирование (архивацию) базы данных АБС RS-Bank необходимо:
1) С консоли сервера базы данных выполнить команду:
BUTIL -STARTBU sourceFile | @listFile>,
где
sourceFile - полный абсолютный путь к файлу базы данных, который будет копироваться или архивироваться (указывается в случае, если планируется выполнить копирование или архивирование одного файла базы данных);
@listFile - полный абсолютный путь к текстовому файлу, в котором указаны полные абсолютные пути к файлам базы данных, подлежащих копированию/архивации (указывается в случае, если планируется выполнить копирование или архивирование нескольких файлов базы данных).
2) Запустить утилиту копирования или архиватор.
3) С консоли сервера базы данных выполнить команду:
BUTIL -ENDBU /A | sourceFile | @listFile>
где
sourceFile - полный абсолютный путь к файлу базы данных, для которого было выполнено копирование или архивирование (указывается в случае, если выполнялось копирование или архивирование одного файла базы данных);
@listFile - полный абсолютный путь к текстовому файлу, в котором указаны полные абсолютные пути к файлам базы данных, для которых было выполнено копирование или архивирование (указывается в случае, если выполнялось копирование или архивирование нескольких файлов базы данных);
/A - применить команду endbu ко всем файлам базы, по которым включен режим continuous operations.
После выполнения первого шага, в директории базы данных будут созданы файлы, имена которых будут совпадать с именами копируемых (архивируемых) файлов базы данных, и имеющие расширение "^^^". В данных файлах будут сохраняться транзакции, генерируемые пользователями во время работы процедуры копирования (архивации). После выполнения третьего шага, транзакции, сохраненные в файлах *.^^^ будут выполнены, в результате чего будет произведена модификация данных в соответствующих файлах БД.

[Barin]

Есть такой продукт, называется Pervasive Backup Agent.
Вот выдержка из документации:
Product Features
Pervasive Backup Agent works seamlessly with many of the most popular backup applications on the market today.

Pervasive Backup Agent manages files that are opened during a backup automatically for you, unlike the Continuous Operations feature in the Pervasive.SQL utilities, which requires that you to enter a list of specific file names.

Lastly, once you have installed Backup Agent with the Pervasive.SQL Server and implemented the agent to work with your specific backup routine, you are ready to start backing up your Pervasive.SQL databases. There are no special configuration settings required.

[Rufat]

У себя в Банке сделал горячий бакэп. Но от этого работать стало труднее. Т.е. при работе в РС Банке стало чувствоваться задержка в работе. И я на фиг отключил ее. Бакэп делается ночью. и все нормально.

[Rufat]

У себя в Банке сделал горячий бакэп. Но от этого работать стало труднее. Т.е. при работе в РС Банке стало чувствоваться задержка в работе. И я на фиг отключил ее. Бакэп делается ночью. и все нормально.

[dd]

klinkin про butil я уже лет 10 знаю
я думал, есть менее тормозные вещи...
а виртуализация тут не поможет? или кластеры какие-нить?

[KaMPiLeR]

ночной баскуп + document.doc ну в зависимости от того как растет - ну раз в 20 минут делай butil -copy.

Для восстановления:
переименовывай document.doc -> postdoc, documnt$.dbt -> postdoc$.dbt
ну если нужно еще и от других глав - ищи сам.
Заходим в отложенные и проводим.
Ну и счета нужно открыть за день открываемые.
Все. 100% работает.

[Smolenkov]

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

PS. А Бутиль документ.дбт - мы "отдадим детям", и пусть у них пройдёт архивная проводка в валюте.

[dd]

Smolenkov а какого софтового агента встроенного в драйвер СУБД ты знаешь?

[KaMPiLeR]

Smolenkov
е-мае, а мужики то не знают - ну расскажи

[Smolenkov]

Самым надёжным считается вариант с "железной" репликацией
[+] любая транзакция записи в любую область хранилища автоматически реплицируется на такое же хранилище территориально отнесённое
[-] у первасива есть такое понятие как кэш и в нём может жить какая-нибудь транзакция изменения (а не дай бог включена отложенная запись.. тут данные и хоронятся)
[-] цена вопроса (за консультацией можете обратиться в тот же ЕМС - поверьте мало не покажется, но каждый тут считает что для него важнее и дороже 4 часа работы операционистов по вбиванию платежек или 1 минута на восстановление

----------------------------
Возвращаясь к вопросу: какие знаешь для первасива программноаппаратные реплики видел:
[:STRENDS] Pilot CDP, + еще можно упомянуть опять же ЕМС и т.д..
----------------------------

[Pov]

не дай бог включена отложенная запись..
Слушай, а напомни, где этот параметр включается? Чё-то я посмотрел - нету вроде. А то тут беда какая-то второй день происходит - проведённый документ кидаем в отложенный - остатки и обороты по одному из счетов не меняются. Повторить не удаётся, опера клянутся, что делают всё как обычно. Однако документ - другой в день таким образом наворачивается.

[Smolenkov]

Когда происходит такая ерунда с проводками рекомендую обратить внимание на 2 вещи:
1. Настройка самого Первасива (уделите внимание параметру Transction Durability (вроде так зпишется) поставьте его в значение OFF
2. Обратите внимание на ини-файл в каталоге ОБЖ: rsreq.ini
3. И чуть не забыл: утановите параметр Allow Cash Engine Connection в значение офф (очень влияет при разделенных серверах БД и приложений)

[Smolenkov]

Еще вариант:
настройки контроллера RAID (вроде как там можно регулировать длинну очереди на чтение/запись - кэширование вещь очень тонкая)...

[Pov]

Allow Cash Engine Connection Угумс. Вот это стояло в on. Но у нас сервер приложений и баз на одной машине. И года три ни одной проблемы не было. А тут вдруг посыпалось. Ладно, поставим в off, понаблюдаем.

В рэйде тоже все буферы отключены - режим записи write thru, чтение - no read ahead. Чудеса...

[mispol]

У себя в Банке сделал горячий бакэп. Но от этого работать стало труднее. Т.е. при работе в РС Банке стало чувствоваться задержка в работе. И я на фиг отключил ее. Бакэп делается ночью. и все нормально.

А при горячем бэкапе у вас сохранялась консистентность БД? Т.е. если в момент начала бэкапа будут обрабатываться проводки, возможно они скопируются в таком виде и в бэкап? Или rs их откатит?

Как вы думаете, задержки были связаны с дополнительной нагрузкай на сервер из-за того, что копировались данные или из-за неоптимального реэима работы pervasive? Наблюдались-ли существенные задержки после окончания бэкапа, когда pervasive переносил в базу данные из временных файлов,

[KaMPiLeR]

ИМХО баловство все это горячее резервирование.
делается проще - полный архив ночью и в макросы document при проводке повесить запись полной структуры в лог, если восстанавливаемся - берем ночьной архив, проводки в отложенные и проводим.
отчеты цб и прочее нужно будет или пересчитывать или по бумажкам вводить (например счета фактуры)

[dd]

всем привет!
надеюсь, не все ещё на ораклы перешли?
может быть, в последнем первазиве появилось что-то более стоящее?
продукт Pervasive DataExchange никто не пробовал?

при проводке повесить запись полной структуры в лог...

не хочется потом разбираться - что из этого действительно провели, а что передумали/удалили/отложили...