Галактика в вопросах и ответах

В текущий выпуск выпуск документации к Галактике входит новый документ "Резервное копирование и восстановление базы данных (Oracle)".

В документе приведены базовые сведения по созданию резервных копий базы данных (БД) системы Галактика ERP (Атлантис версии 5.4.36 и выше) на платформе Oracle.

Информация, описанная в документе, не заменяет документации Oracle, однако дает представление о рекомендуемом подходе, а также минимально необходимые теоретические сведения о резервном копировании и восстановлении БД в случае сбоя.

В документе приведены сценарии и примеры скриптов для создания резервных копий БД и восстановления из них.

Ссылки на документ:
ftp://ftp.galaktika.ru/pub/support/gala ... kupOra.pdf
ftp://ftp.galaktika.ru/pub/support/gala ... kupOra.chm

Рекомендую администраторам Галактики: Почитать документ. Ответить в этой ветке форума пригодился документ или нет? Высказать предложения о улучшению документа.

Почитал. Почему не пригодится? Пригодится. Подробно. Доступно.
Хочу сказать о документе i_ora.chm см. главу "Перемещение базы данных системы Галактика ERP в другой экземпляр базы данных Oracle" (тема та же). В п.2 есть фразы:

- Выполнить выгрузку пользователей и ролей, используя следующий скрипт:
- Выполнить выгрузку привилегий, используя следующий скрипт:

а самих скриптов нет. Надо добавить. И еще хотелось бы иметь такую же инструкцию только с изменением имени схемы галактики.

LaaLaa писал(а):Рекомендую администраторам Галактики: Почитать документ. Ответить в этой ветке форума пригодился документ или нет? Высказать предложения о улучшению документа.

Одна из наших админ Оракл почитала, ответила, что вещь полезная и её батники почти такие же для этих нужд.

Хотелось бы увидеть еще документ "Резервное копирование и восстановление базы данных (MSSQL)"

Спасибо за отзывы.

Andrey писал(а): Хочу сказать о документе i_ora.chm см. главу "Перемещение базы данных системы Галактика ERP в другой экземпляр базы данных Oracle" (тема та же). В п.2 есть фразы:

- Выполнить выгрузку пользователей и ролей, используя следующий скрипт:
- Выполнить выгрузку привилегий, используя следующий скрипт:

а самих скриптов нет. Надо добавить.

В I_ora.chm действительно имеется ошибка сборки документа, выражающаяся в отсутствии части текста. В очередном издании это будет исправлено. Пока придется использовать pdf-вариант этого документа (там скрипты приведены).
ftp://ftp.galaktika.ru/pub/support/gala ... /i_ora.pdf

Andrey писал(а):И еще хотелось бы иметь такую же инструкцию только с изменением имени схемы галактики.

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

Начинающий путь писал(а):Хотелось бы увидеть еще документ "Резервное копирование и восстановление базы данных (MSSQL)"

пока такой документ обещать не могу

LaaLaa писал(а):
Обсудим это с коллегами, и как появится время дополним документ. Только в случае с Oracle практичнее будет создавать новый эеземпляр, а не изменять имя схемы. Полагаю изменение имени нужно для того чтобы создать копию БД для тестов?

Да, разговор идет о подъеме тестовой базы

i_sql не читали? Если делать в точности как там написано, то пашет. Там мелочь 20 этапов. Я обхожусь 4 где то.

Andrey писал(а): ... И еще хотелось бы иметь такую же инструкцию только с изменением имени схемы галактики.

В общем случае такая операция производится с помощью экспорта существующей базы, создания новой (с желаемым именем) Галактической схемы, содержащей только словарь, и импортом в нее экспортированных на предыдущем шаге данных.
* При этом следует помнить, что для работы с этой Галактической базой параметр FullLoginName должен быть установлен в значение "on".

Выполняется эта работа с помощью утилит Галактики (конвертора), а не с помощью утилит из состава ORACLE или операционной системы.
Объясняется тем, что при создании Галактической базы(схемы), объекты, создаваемые в ORACLE, имеют привязку к имени этой самой Галактической схемы. Триггера, процедуры и функции оперируют данными в конкретных схемах применяя полное имя СХЕМА.ИМЯ_ТАБЛИЦЫ(ОБЪЕКТА).
Простой импорт/экспорт средствами ORACLE изменений в самих объектах не производит.

Как вариант создания тестовой конфигурации может быть применен метод клонирования экземпляра ORACLE на другой или этот же сервер, если его ресурсы позволяют одновременно эксплуатировать два экземпляра.
При этом имя экземпляра-клона будет(должно быть) изменено, а имя Галактической БД останется таким же.
В зависимости от режима эксплуатации основного экземпляра, такое клонирование может быть выполнено либо с остановкой его (NOARCHIVELOG), либо не прерывая работы (режим работы ARCHIVELOG).

Вот где-то так.

AlexMK писал(а): В общем случае такая операция производится с помощью экспорта существующей базы, создания новой (с желаемым именем) Галактической схемы, содержащей только словарь, и импортом в нее экспортированных на предыдущем шаге данных.
* При этом следует помнить, что для работы с этой Галактической базой параметр FullLoginName должен быть установлен в значение "on".

Выполняется эта работа с помощью утилит Галактики (конвертора), а не с помощью утилит из состава ORACLE или операционной системы.
Объясняется тем, что при создании Галактической базы(схемы), объекты, создаваемые в ORACLE, имеют привязку к имени этой самой Галактической схемы. Триггера, процедуры и функции оперируют данными в конкретных схемах применяя полное имя СХЕМА.ИМЯ_ТАБЛИЦЫ(ОБЪЕКТА).
Простой импорт/экспорт средствами ORACLE изменений в самих объектах не производит.

Как вариант создания тестовой конфигурации может быть применен метод клонирования экземпляра ORACLE на другой или этот же сервер, если его ресурсы позволяют одновременно эксплуатировать два экземпляра.
При этом имя экземпляра-клона будет(должно быть) изменено, а имя Галактической БД останется таким же.
В зависимости от режима эксплуатации основного экземпляра, такое клонирование может быть выполнено либо с остановкой его (NOARCHIVELOG), либо не прерывая работы (режим работы ARCHIVELOG).

Вот где-то так.

Вот и делаю подъем тестовой базы с помощью галактического конвертора уже не один год. Долго только выходит по времени. А что касается клонирования, то первый вопрос в аккуратности работы с обеими базами одновременно. Дабы не перепутать, что в какой нужно сделать. Отличие только в надписи галактики [БД-серевер-экзкмпляр-схема]. У меня человек умудрился период в зарплате закрыть в рабочей базе, а нужно было в тестовой.

Что-то я не пойму - эти "прелести" с тестовой базой на оракле даже в пределах домена?

Andrey писал(а): ...А что касается клонирования, то первый вопрос в аккуратности работы с обеими базами одновременно. Дабы не перепутать, что в какой нужно сделать. Отличие только в надписи галактики [БД-серевер-экзкмпляр-схема].

Согласитесь Андрей, что невнимательный пользователь с тем же результатом может не заметить и различие в наименовании Галактической схемы.
Тут должен техпроцесс быть налажен и строгая регламентация в части обеспечения сохранности боевой БД.

К примеру - тестирование строго через работу в терминальной сессии в изолированной от боевого контура тестовой среде, из которой нет доступа к боевой БД может решить часть вопросов.

Но по определению - от человеческих ошибок защититься нереально.

Polimer писал(а):Что-то я не пойму - эти "прелести" с тестовой базой на оракле даже в пределах домена?

нет у меня домена

у нас в организации (внедрение еще не закончено) базу из бэкапа (оракл) разворачивают от 18 часов и более, утверждают что это нормально, но сильно подозреваю что это не может быть нормальным, день клиенты выключены из работы, ответьте пожалуйста, сколько по времени в среднем должна занимать эта операция?

с моей точки зрения, вопрос поставлен не корректно. Какая политика бэкапов? Какая база (рабочая или какая другая) поднимается и из какого бэкапа (в смысле как выполненного)? Шустрость железа? А вы и по выходным работаете, если 18 часов для вас критично?
ЗЫ у меня время подъема тестовой база с помощью галактического конвертора занимает 3 суток. Объем выгруженных в дбф файлов 26,5Гб