Снова перенос базы под Ораклом

[smv]

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

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

[VAt]

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

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

[smv]

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

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

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

[VAt]

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

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

[Andrey]

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

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

[VAt]

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

[LaaLaa]

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

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

[VAt]

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

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

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

[edward_K]

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

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

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

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

[VAt]

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 тоже вполне хватает.