История одной миграции 2
Igor Zavgorodny
миграцию, зато появилось время для тестов.
Напомню суть, перезжаем с 7.31.UC5 SCO на 9.21.UC2 Intel Solaris.
Основной проблемой при прошлом перезде являлась необходимость перевода на
старом сервере базы данных в нелоггируемое состояние, а также возврат ее
назад (т.е. два архива 0-го уровня по 5.5 часов). В связи с этим, пришлось
изобретать новый велосипед.
1. Выгрузка в Ascii-Delimited на новый сервер. Как оказалось мое
предположение, что для нелоггируемых баз не используется Read Ahead
оказалось справедливым. Данный этап в результате прошел более чем в 2 раза
быстрее, чем предыдущий (при этом Read Ahead использовался вовсю).
2. Подъем из Ascii-Delimited. Как оказалось, баг, приводящий к пожиранию всей доступной
памяти при загрузке больших таблиц, содержащих varchar, устранее только в
версии 9.21.UC3, которой я пока не располагаю :-(. Багу подверженны
dbimport, dbaccess (load), dbload. Причем последний из них любыми
порциями данных как для логгируемых базах, так и на нелоггируемых ;-(.
От перспективы дробить загрузку на несколько файлов я отказался и все таки
решился изучить HPL, как оказалось он на много проще в освоении, чем
казался вначале. Тяга к знаниям была вознаграждена - 800Мб текстовый
файлик из 4млн записей, который никак не хотела загружаться (по причине
исчерпывания RAM-a), был загружен HPL-ем за 10 минут вместе с созданием
первичного индекса. Другая табличка, на 70 млн записей (2.8Гб), вместо 3-х
часов грузилась 8 минут+ 55 минут. на построение index-а по 3 integer
полям.
Резюме, надо учить матчасть :-).
Regards, Igor.
Serge Komisar
> В связи с проблемным поведением железа мне пришлось несколько отложить
> миграцию, зато появилось время для тестов.
> Напомню суть, перезжаем с 7.31.UC5 SCO на 9.21.UC2 Intel Solaris.
> Основной проблемой при прошлом перезде являлась необходимость перевода на
> старом сервере базы данных в нелоггируемое состояние, а также возврат ее
> назад (т.е. два архива 0-го уровня по 5.5 часов).
Не помню описания прошлого перезда, но разве нельзя было установить
TAPEDEV в /dev/null на время переключения состояния логирования ?
Igor Zavgorodny
>Не помню описания прошлого перезда,
>но разве нельзя было установить
>TAPEDEV в /dev/null на время переключения состояния логирования ?
Конечно можно, а если будут проблемы? А если при переезде посыпется база,
железо и т.д. и т.п. Потом базу тоже из /dev/null восстанавливать? 7
бекапов, лучше чем 5 бекапов :-). Архив 0, все равно прийдется делать
перед перездом. Вопрос был в том, чтобы не делать его опять, если переезд
окажется неудачным и работать прийдется опять на старом сервере.
Regards, Igor.
Vasyl Shulzhenko
"Igor Zavgorodny" <dau...@torba.com> wrote in message
news:3cdfe399$1@proxy...
> 1. Выгрузка в Ascii-Delimited на новый сервер. Как оказалось мое
> предположение, что для нелоггируемых баз не используется Read Ahead
> оказалось справедливым. Данный этап в результате прошел более чем в 2 раза
> быстрее, чем предыдущий (при этом Read Ahead использовался вовсю).
Никак не могу понять взаимосвязь между RA и логируемостью БД.
Может у кого то есть какие то предположения ?
> 2. Подъем из Ascii-Delimited. Как оказалось, баг, приводящий к пожиранию
всей доступной
> памяти при загрузке больших таблиц, содержащих varchar, устранее только в
> версии 9.21.UC3, которой я пока не располагаю :-(. Багу подверженны
> dbimport, dbaccess (load), dbload. Причем последний из них любыми
> порциями данных как для логгируемых базах, так и на нелоггируемых ;-(.
> От перспективы дробить загрузку на несколько файлов я отказался и все таки
> решился изучить HPL, как оказалось он на много проще в освоении, чем
> казался вначале. Тяга к знаниям была вознаграждена - 800Мб текстовый
> файлик из 4млн записей, который никак не хотела загружаться (по причине
> исчерпывания RAM-a), был загружен HPL-ем за 10 минут вместе с созданием
> первичного индекса. Другая табличка, на 70 млн записей (2.8Гб), вместо 3-х
> часов грузилась 8 минут+ 55 минут. на построение index-а по 3 integer
> полям.
>
> Резюме, надо учить матчасть :-).
Да, это надо делать всю сознательную жизнь.
Жаль, что на все просто жизни не хватит :))
--
Igor Zavgorodny
Vasyl Shulzhenko <vas...@mail.ru> сообщил в новостях следующее:
> Никак не могу понять взаимосвязь между RA и логируемостью БД.
> Может у кого то есть какие то предположения ?
Судя по всему, это очередной случай моего "так называемого вранья" или чего
сонным (пьяным) глазам не представится, а потом будешь другим людям месяц
голову морочить. Сейчас проверил свои тезисы по RA, не подвердились,
работает оно как миленькое на нелоггируемой базе, правда есть у меня еще
пара зацепок, чтобы оправдать мое честное вральское слово, но проверить
смогу только на следующей неделе :-).
Regards, Igor.
Vasyl Shulzhenko
"Igor Zavgorodny" <dau...@kreditprombank.com> wrote in message
news:3ce176d4$1@proxy...
Фу-у-у, ну ты меня успокоил, а то я прям заснуть дома не мог :))
Судя по всему, твои заключения надо перепроверять (что, в принципе, всегда
надо делать), а то я раньше так безгранично верил... :))
--
С уважением,
Василий Шульженко
http://training.softline.kiev.ua
Eugene Nechayev
одну из аксиом ;-)
Успокоил, успокоил :)
Евгений
"Vasyl Shulzhenko" <vas...@mail.ru> wrote in message
news:abtq13$i5a$1...@news.lucky.net...