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

перешли еще и ASM подняли
при любом переносе отключается все галактические службы, сноситься журнал
БД переводиться в ноуархивлог)
и перенос сокращался от суток до 2х часов)))

ну конечно не забываем про строки которые конверторе надо раскоментировать
DBFFieldNameSize=24
ImportBatchMode=ON
ImportBatchRowCount=8192

smv писал(а):перешли еще и ASM подняли
при любом переносе отключается все галактические службы, сноситься журнал
БД переводиться в ноуархивлог)
и перенос сокращался от суток до 2х часов)))

А переходили через выгрузку в DBF? Что-то 2 часа больно быстро для экспорта-импорта... А какой размер базы?

VAt писал(а):

smv писал(а):перешли еще и ASM подняли при любом переносе отключается все галактические службы, сноситься журнал
БД переводиться в ноуархивлог) и перенос сокращался от суток до 2х часов)))

А переходили через выгрузку в DBF? Что-то 2 часа больно быстро для экспорта-импорта... А какой размер базы?

разный размер у БД их много экспериментируете если не верите сравнивайте)

smv писал(а):разный размер у БД их много экспериментируете если не верите сравнивайте)

У самой большой базы какой размер? Ну или сколько записей в таблице оборот? Эксперимент мне еще предстоит, просто интересно, реально что-то убыстрили?

VAt писал(а): И второй вопрос: Есть, кто работает на Галактике 9 под Ораклом 9? или все мигрировали уже на 10g-11g?

To VAt: хотелось бы узнать, а какие у вас трудности, если "Галактика 9 под Ораклом 9"?

У меня никаких, требование руководства, мол изменились системные требования для Галактика 9, сейчас минимальная версия Оракла должна быть 10g.

Oracle 9.2 сейчас не поддерживаться самим Ораклом. Если переходите то лучше на 11g.

А в Галактике патчи на Oracle 9.2 уже давно не проверяем. Как и на Windows 2000.
Пока работает но с новыми патчами может перестать работать. 15 лет прошло пора менять версии.

Мы ведем работы по переходу на новую версию Oracle , естественно на 11.2 Но есть нюанс, средствами конвертера не получается пока уложиться в установленные сроки: 3 суток.

Экспорт дбф: сутки
Импорт дбф: 3 суток.
Создание индексов: почти сутки.
Пересчет прав: Не менее 15 часов.

Внимание вопрос, как перейи за 3 суток? А ведь еще надо и журнал зачистить:)

1. Прочитать про распаралеривовыния в readme.txt от старого конвертора
2. А где там экспорт импорт? что то не увидел в конверторе 810-910. Вот то , что требуется установить все патчи с alter для начала увидел - в readme. Это делаете отдельно.
3. А вы как конвертируете? Чем то своим?
4. Ест. конвертацию лучше запускать на серваке - и выше уже писали, что сделать.
5. Насчет прав - лучше включить групповые роли. Если делаете новую базюку, то лучше это сделать сразу. Иначе советуют еще старые права грохнуть - поищите на forum.galaktika.by, хотя и так включал. Ест. включать нужно и в галактике и в сапорте одновремено.
6. Конвертация СУБД самое время для оптимизации самого сервера. Я обычно советую организовать два раида или для критичных данных раид, что можно восстановить - просто винт, но отдельный - чтобы туда например вынести индексы логи и прочую фигню. Да и памяти лишне не будет добавить. SQL так охотно сожрал 128 гиг и не подавился.
PS сам переход пока не делал.

edward_K писал(а):1. Прочитать про распаралеривовыния в readme.txt от старого конвертора
2. А где там экспорт импорт? что то не увидел в конверторе 810-910. Вот то , что требуется установить все патчи с alter для начала увидел - в readme. Это делаете отдельно.
3. А вы как конвертируете? Чем то своим?
4. Ест. конвертацию лучше запускать на серваке - и выше уже писали, что сделать.
5. Насчет прав - лучше включить групповые роли. Если делаете новую базюку, то лучше это сделать сразу.

Код: Выделить всё

// --------------------------
[SQLDriver]
! Используется групповые роли на сервере СУБД
UseSqlRole=On

Иначе советуют еще старые права грохнуть - поищите на forum.galaktika.by, хотя и так включал. Ест. включать нужно и в галактике и в сапорте одновремено.
6. Конвертация СУБД самое время для оптимизации самого сервера. Я обычно советую организовать два раида или для критичных данных раид, что можно восстановить - просто винт, но отдельный - чтобы туда например вынести индексы логи и прочую фигню. Да и памяти лишне не будет добавить. SQL так охотно сожрал 128 гиг и не подавился.
PS сам переход пока не делал.

1. Да, для импорта будем пробовать распараллелить. С экспортом эта тема прокатит?
2-3. Конвертер 910-910
4. за пускаем на виндовом сервере с екзешниками, сама база у нас на Oracle Solaris (SUN).
5. Первый пересчет с SQL ролями тоже не быстро по времени идет.
6. У нас дисковый массив стоит с 5ым рэйдом, вполне достаточно, подсоединен на 2 контроллера. Памяти для Oracle тоже вполне хватает.