История одной миграции
Igor Zavgorodny
Я сейчас переношу небольшую базу (14 Гб) на новый сервер. В процессе
миграции возникли некоторые вопросы, которые навернека встали перед
многими здесь присутствуюшими.
Исходные данные:
2xPProx200Mhz, 256 RAM, RAID-5 на 3-х 18.2Гб 7200 дисках, SCO 5.0.2; IDS
7.31UC5
В эксплуатации 5 лет, заменены винты 2 года назад + 1.5 года назад
миграциия IDS с 7.22 на 7.31.
Архив нулевого уровня на ленту - 5.5 часов. Основные причины миграции -
неудовлетворительное время подъема в случае краха, места по дискету
Платформа.
Тут сразу вспоминается фраза "наши реалии", сказанная Василием Шульженко о
конфигурации, описанной Евгением Нечаевым всего то в июле 2001 года
:-).http://groups.google.com/groups?hl=uk&threadm=9js6qd%24ggd%241%40news.lucky.net&rnum=1&prev=/groups%3Fq%3Dukr.comp.dbms.informix%2BRAID%2B%25E4%25F0%25F3%25E3%26hl%3Duk
OS.
К сожалению, RISC платформы, несмотря на серьезное снижение цен, все таки
идут лесом. Поэтому выбирать приходится из Caldera, Solaris x86, Linux.
Несмотря на предстоящее прекращение поддержки Solaris-a x86 я все таки
остановился на нем .У меня нет времени на эксперименты с Linux, а
поставщик прикладного софта пока не позиционирует его в качестве основной
платформы. По поводу продукции Caldera, возможно она имеет определенное
будующее, но я выбираю платформу сейчас, а через 5 лет посмотрим. Про M$
как обычно либо ничего, либо только ... :-)
Железо.
Понятно дело, что насмотревшись на конфигурацию имени Жени, я сидел на
пальцах прикидывал свой бюджет, и обнаружил в нем возможность закупки
"4-ых канального RAID". Впрочем, стоит учесть еще одну именно "нашу
особенность". В буржуинщине никто никогда не купит железо, которого нет в
"Hardware compatabile list", выбранной им OS. Впрочем Соляру x86 на новый
продакшен сервер в 2002 году тоже наверняка никто не поставит :-).
Воспользовавшись услугами телеграфного агенства ОБС, я выяснил, что
приобретаемое мною железо с Солярой справится и особых проблем за ним не
замеченно (пара проблем все таки нашлась, но оказалась вполне преодолима).
Основным недостатком оказалось, что Соляра не видела больше 7-логических
дисков, сконфигурированных на RAIDe. (впрочем сам RAID-контролер может
сделать их только 8-м). В результате имеем такую организацию:
1.2Гб ОЗУ, 2x1.26PIII, 4-ых канальный RAID 128Мб ОЗУ .....
RAID-стойка на 14 дисков разбита на 6 логических дисков в 1-м RAID-е, +2
винта в Hot Spair (запас как известно ж... не "трогает"):
0-й диск - система
1-й диск - rootdbs
2-й диск - physical & logical logs
3-5 диски - на каждом по dbspac-у для данных
Данные первоначально планировалось фрагментировать по ROUND ROBIN, но
учитывая, что 9-ка имеет индексы DETACHED и в 9.3 судя по всему нет уже и
workaround-а для некоторых из них (DEFAULT_ATTACH), т.е. индексы надо либо
фрагментировать по условию, что конечно производительно, но трудоемко, тем
более, что сервер планируется сделать с минимальными требованиями ко
времени DBA на ближайшие 3 года. В связи с этим наверное будет round-robin
на 2 dbspace для данных и отдельный dbspace под индексы. либо какое-нибудь
совсем другое разбиение (соотношение данных к индексам у меня примерно
55/45).
Ну и венец творения - 4x18.2 Гб SCSI диска , не влезших в RAID -стойку, на
каждом по 2Гб tempdbspace + партиции для ночных бекапов, DVD фильмов и
т.д.
IDS. 9.21.UC2
Перенос данных:
При таком раскладе оффициальных мигрейшен тулов - два (dbexport и HPL).
Веру в dbexport для сколько нибудь больших объемов данных я утратил
достаточно давно. Разбиратся с HPL или с myexport by Art.S.Kagel время
традиционно не нашлось. По этому было опробованно решение "в лоб", т.е.
без потерь времени на выгрузку в файлы:
1. На старом сервере добавляем новый сервер в host.equiv
2. На новом сервере старый сервер в sqlhosts.
3. База на старом сервере переводится в режим "no logging".
4. dbschema делится на две части, 1-я создание таблиц и индексов, 2-я
создание foreign-констрейнтов, процедур, триггеров.
5. Создается первая часть БД.
6. Переливаются данные запросами типа "insert into table select * from
database@oldserver:table"
7. Выполняется вторая часть скрипта.
На мой взгляд я добился максимально быстрой загрузки (4 часа на закачку
данных и 2.5 часа - построение констрейнтов, триггеров и процедур), ибо
она была ограничена быстродействием старого сервера (проверка
осуществлялась сравнением времени выполнения предыдущего запроса и "unload
to /dev/null select * from table"). При меньшей разнице в
производительности серверов видимо более предпочтительным было бы
создавать все индексы во второй части.
Возможные варианты повышения производительности:
1. Почему-то на старом сервере абсолютно не использовался Read Ahead
(может он просто не работает для нелоггируемых баз ?).
2. Параллельная загрузка нескольких таблиц.
3. Упорядочивание загрузки таблиц так, чтобы сначала загрузить
"REFERENCED", а затем "Referential". Кстати, наверняка сущестуют тулзы
позволяющие делать это автоматически. Дабы потом загружать данные имея
только отключенные триггера ибо, повторюсь, основные тормоза дает старый
сервер.
Regards, Igor.
P.S. Любые комментарии и вопросы приветствуются.
Vasyl Shulzhenko
процесс.
Тут прямо готовая инструкция для тех "несчастных, которым такие процедуры
еще предстоят в будущем...
"Igor Zavgorodny" <dau...@torba.com> wrote in message
news:3cc42964$1@proxy...
....
> Платформа.
> Тут сразу вспоминается фраза "наши реалии", сказанная Василием Шульженко о
> конфигурации, описанной Евгением Нечаевым всего то в июле 2001 года
>
:-).http://groups.google.com/groups?hl=uk&threadm=9js6qd%24ggd%241%40news.lu
cky.net&rnum=1&prev=/groups%3Fq%3Dukr.comp.dbms.informix%2BRAID%2B%25E4%25F0
%25F3%25E3%26hl%3Duk
Прямо заинтриговал :)
Пришлось идти таки по ссылке и читать - чего же там такого сказано ?
Оказалось, ничего интересного для "наших реалий" :))
> OS.
...
> будующее, но я выбираю платформу сейчас, а через 5 лет посмотрим. Про M$
> как обычно либо ничего, либо только ... :-)
ну и ладно, "мы" не в обиде :))
> Железо.
....
> 1.2Гб ОЗУ, 2x1.26PIII, 4-ых канальный RAID 128Мб ОЗУ .....
>
> RAID-стойка на 14 дисков разбита на 6 логических дисков в 1-м RAID-е, +2
> винта в Hot Spair (запас как известно ж... не "трогает"):
Кстати, а винты то какого размера ?
А не думал сделать RAID 10 ?
> 0-й диск - система
> 1-й диск - rootdbs
> 2-й диск - physical & logical logs
Вот тут я не согласен. Логи (физ. и логич.) нужно обязательно разделять, тем
более, что это одна из наиболее активных зон по интенсивности записи (если
, конечно, есть транзакционная активность ).
> 3-5 диски - на каждом по dbspac-у для данных
А как диски висят на 4-х каналах ? Надеюсь, зеркальные пары на разных
контроллерах ? (ну это я так, на всякий случай спросил, чтобы
продемонстрировать эрудицию :))
Да, а все на файлы или в raw ?
> Данные первоначально планировалось фрагментировать по ROUND ROBIN, но
> учитывая, что 9-ка имеет индексы DETACHED и в 9.3 судя по всему нет уже и
> workaround-а для некоторых из них (DEFAULT_ATTACH), т.е. индексы надо либо
> фрагментировать по условию, что конечно производительно, но трудоемко, тем
> более, что сервер планируется сделать с минимальными требованиями ко
> времени DBA на ближайшие 3 года. В связи с этим наверное будет round-robin
> на 2 dbspace для данных и отдельный dbspace под индексы. либо какое-нибудь
> совсем другое разбиение (соотношение данных к индексам у меня примерно
> 55/45).
Я бы делал немного по другому. Правда, здесь нужна бы старая статистика
использования таблиц.
При более менее равномерном использовании размазал бы рабочие спейсы по всем
6 дискам и создавал бы чанки по очереди на каждом из них (это, если не
возится с фрагментацией). Хотя... и RR пойдет, учитывая сплошное
зеркалирование (но уж как то не хочется на каждый запрос шебуршать всеми
винтами).
> Ну и венец творения - 4x18.2 Гб SCSI диска , не влезших в RAID -стойку, на
> каждом по 2Гб tempdbspace + партиции для ночных бекапов, DVD фильмов и
> т.д.
>
> IDS. 9.21.UC2
>
> Перенос данных:
> При таком раскладе оффициальных мигрейшен тулов - два (dbexport и HPL).
> Веру в dbexport для сколько нибудь больших объемов данных я утратил
> достаточно давно. Разбиратся с HPL или с myexport by Art.S.Kagel время
> традиционно не нашлось. По этому было опробованно решение "в лоб", т.е.
> без потерь времени на выгрузку в файлы:
>
> 1. На старом сервере добавляем новый сервер в host.equiv
> 2. На новом сервере старый сервер в sqlhosts.
> 3. База на старом сервере переводится в режим "no logging".
> 4. dbschema делится на две части, 1-я создание таблиц и индексов, 2-я
> создание foreign-констрейнтов, процедур, триггеров.
> 5. Создается первая часть БД.
> 6. Переливаются данные запросами типа "insert into table select * from
> database@oldserver:table"
> 7. Выполняется вторая часть скрипта.
>
>
> На мой взгляд я добился максимально быстрой загрузки (4 часа на закачку
> данных и 2.5 часа - построение констрейнтов, триггеров и процедур), ибо
Как то мало, учитывая 5-и часовый 0-й архив.
> она была ограничена быстродействием старого сервера (проверка
> осуществлялась сравнением времени выполнения предыдущего запроса и "unload
> to /dev/null select * from table"). При меньшей разнице в
> производительности серверов видимо более предпочтительным было бы
> создавать все индексы во второй части.
Странно, что ты все таки строил индексы, а потом грузил данные.
Я понял, что это тормозов не вызывало, но как то нелогично :)
Я бы над этим даже не думал...
> Возможные варианты повышения производительности:
> 1. Почему-то на старом сервере абсолютно не использовался Read Ahead
> (может он просто не работает для нелоггируемых баз ?).
По моему, он преимущественно используется для чтения индексов, а в твоем
случае они вряд ли использовались.
> 2. Параллельная загрузка нескольких таблиц.
> 3. Упорядочивание загрузки таблиц так, чтобы сначала загрузить
> "REFERENCED", а затем "Referential". Кстати, наверняка сущестуют тулзы
> позволяющие делать это автоматически. Дабы потом загружать данные имея
> только отключенные триггера ибо, повторюсь, основные тормоза дает старый
> сервер.
>
>
> Regards, Igor.
>
> P.S. Любые комментарии и вопросы приветствуются.
Это всегда пожалуйста, лишь бы время было :)
--
С уважением,
Василий Шульженко
http://training.softline.kiev.ua
Sergey E. Volkov
"Igor Zavgorodny" <dau...@torba.com> сообщил/сообщила в новостях следующее:
news:3cc42964$1@proxy...
> Hi All.
> Я сейчас переношу небольшую базу (14 Гб) на новый сервер. В процессе
> миграции возникли некоторые вопросы, которые навернека встали перед
> многими здесь присутствуюшими.
>
> Исходные данные:
> 2xPProx200Mhz, 256 RAM, RAID-5 на 3-х 18.2Гб 7200 дисках, SCO 5.0.2; IDS
> 7.31UC5
> В эксплуатации 5 лет, заменены винты 2 года назад + 1.5 года назад
> миграциия IDS с 7.22 на 7.31.
> Архив нулевого уровня на ленту - 5.5 часов. Основные причины миграции -
> неудовлетворительное время подъема в случае краха, места по дискету
>
> Платформа.
> Тут сразу вспоминается фраза "наши реалии", сказанная Василием Шульженко о
> конфигурации, описанной Евгением Нечаевым всего то в июле 2001 года
>
:-).http://groups.google.com/groups?hl=uk&threadm=9js6qd%24ggd%241%40news.lu
cky.net&rnum=1&prev=/groups%3Fq%3Dukr.comp.dbms.informix%2BRAID%2B%25E4%25F0
%25F3%25E3%26hl%3Duk
>
> OS.
> К сожалению, RISC платформы, несмотря на серьезное снижение цен, все таки
> идут лесом. Поэтому выбирать приходится из Caldera, Solaris x86, Linux.
> Несмотря на предстоящее прекращение поддержки Solaris-a x86 я все таки
?????
Однако откуда дровишки ? Насколько я знаю они заявили, что приостанавливают
Solaris 9 для IA32 до выяснения 'рыночной ситуации', а восьмерку будут
потдерживать
в течение 7 лет.
Однако дня три назад я видел вот это: Sun rethinks Solaris on Intel
http://www.infoworld.com/articles/hn/xml/02/04/19/020419hnsecretsix.xml
Вообще это очень странно. Что то Sun темнит. Что то говорит мне, вся 'суета
вокруг дивана' это просто 'военная хитрость' ...
Действующих лицензий (зарегистрированных на Sun Tech. Support ) для Solaris
8 IA 1.2 миллиона !
(У Informix ~ 100 000.) Бросать Sol на IA это рыть себе могилу - мое
мнение.
Что касается производительности, то под Linux она будет немного повыше, чего
однако
никак нельзя сказать про надежность - ну просто нельзя сравнивать.
Опять таки Solaris просто глупо ставить на однопрцессорную тачку.
> остановился на нем .У меня нет времени на эксперименты с Linux, а
> поставщик прикладного софта пока не позиционирует его в качестве основной
> платформы. По поводу продукции Caldera, возможно она имеет определенное
> будующее, но я выбираю платформу сейчас, а через 5 лет посмотрим. Про M$
> как обычно либо ничего, либо только ... :-)
>
> Железо.
> Понятно дело, что насмотревшись на конфигурацию имени Жени, я сидел на
> пальцах прикидывал свой бюджет, и обнаружил в нем возможность закупки
> "4-ых канального RAID". Впрочем, стоит учесть еще одну именно "нашу
> особенность". В буржуинщине никто никогда не купит железо, которого нет в
> "Hardware compatabile list", выбранной им OS. Впрочем Соляру x86 на новый
> продакшен сервер в 2002 году тоже наверняка никто не поставит :-).
Почему ?
> Воспользовавшись услугами телеграфного агенства ОБС, я выяснил, что
> приобретаемое мною железо с Солярой справится и особых проблем за ним не
> замеченно (пара проблем все таки нашлась, но оказалась вполне преодолима).
> Основным недостатком оказалось, что Соляра не видела больше 7-логических
> дисков, сконфигурированных на RAIDe. (впрочем сам RAID-контролер может
Поставь Solstice Disk Suite. ( Можно свободно скачать с Sun )
Igor Zavgorodny
>Сначала, огромное спасибо за то, что не поленился так подробно описать
весь
>процесс.
>Пришлось идти таки по ссылке и читать - чего же там такого сказано ?
>Оказалось, ничего интересного для "наших реалий" :))
Имелся ввиду четырех-канальный RAID и куча винтов.
>Кстати, а винты то какого размера ?
18.2Гб 10000об, я не Рокфеллер :-)
>А не думал сделать RAID 10 ?
Думал и изначально даже сделал. Помнится когда, я два года назад плакался,
какой SCO нехороший, умеет только 28-партиций, народ говорил ja-ja-ja,
надо OS менять и винты в RAID не загонять :-). Но даже на 4-ых винтах R10
- это уже 36Гб, учитывая. что имеем x86 Solaris, то даже с извращениями с
помощью raw-device можно использовать не больше 32Гб на одном диске (о
9.30 в промышленной эксплуатации пока что речь не идет, впрочем как и о
технологиях разбиения дисков от платных стороних производителей типа
Veritas).
>> 0-й диск - система
>> 1-й диск - rootdbs
>> 2-й диск - physical & logical logs
>Вот тут я не согласен. Логи (физ. и логич.) нужно обязательно разделять,
тем
>более, что это одна из наиболее активных зон по интенсивности записи
(если
>, конечно, есть транзакционная активность ).
Согласен, мне самому не нравится. Но дисков получилось всего 6. Объединять
логи с данными не хочется, поэтому я сейчас сижу гоняю тесты куда их
запихнуть.
>> 3-5 диски - на каждом по dbspac-у для данных
>А как диски висят на 4-х каналах ?
В результате используются всего два канала (это по поводу наших условий
:-). Так как главное для меня быстрое восстановление, диски, которые
находятся сервера, а не в RAID-стойке я использовать в конфигурации
RAID-a не могу.
При текущей конфигурации, самая страшная беда (тьху-тьху) - это
одновременное умирание двух зеркальных винтов в стойке - время
восстановления 40Гб архива нулевого - 1 час. Логов в день у меня не так
много (порядка 200Мб).
>Надеюсь, зеркальные пары на разных контроллерах ?
Контролер один, я так понимаю ты имел ввиду разные каналы, эти конечно
разные, так что отрыв одного шнурка мне не грозит. Кроме того, я собираюсь
сделать обмен с более старым братом этого сервера, с тем, чтобы винты были
из ранних партий. На винты, имени TEMPDBSPace, стоящие не в RAID, по ночам
будет делатся доп. бекап.
>Да, а все на файлы или в raw ?
Как уже было сказано все в raw. Хотя очень подкупает идея добить мозгов до
2Гб (их есть у меня), и вынести tempdbspace в /tmp отдав на откуп UNIX-у
работу с ним (пока мозгов хватает Соляра держит все содержимое /tmp там).
Индексы я каждый день не строю, юзеров у меня немного, в tempdb за всю
историю наблюдений не было использовано больше 200Мб при нормальной
работе.
>Я бы делал немного по другому. Правда, здесь нужна бы старая статистика
>использования таблиц.
>При более менее равномерном использовании размазал бы рабочие спейсы по
всем
>6 дискам и создавал бы чанки по очереди на каждом из них (это, если не
>возится с фрагментацией). Хотя... и RR пойдет, учитывая сплошное
>зеркалирование (но уж как то не хочется на каждый запрос шебуршать всеми
>винтами).
Тут скорее необходимо понимание всей специфики системы.
1. Почему не хочется мазать данные на диск, на котором живет система. Дело
в том, что через серверок проходит в день несколько тысяч файлов и
файликов и есть куча роботов, которые регулярно эти файлики порождают,
перекладывают, ждут, а не появилось ли чего и т.д. Т.е. нагрузка на этом
винте не только от системы.
2. Сервер (что традиционно для нашего рынка) одновременно OLTP,
DSS(несколько раз в день) и OLAP (правда без МетаКубических наворотов).
Поэтому в зависимости от времени дня кто-то является главным и кого именно
можно было бы наиболее безболезненно перенести, например к physdbs, я
сразу и не скажу (но за идею спасибо).
>> На мой взгляд я добился максимально быстрой загрузки (4 часа на
закачку
>> данных и 2.5 часа - построение констрейнтов, триггеров и процедур),
ибо
>Как то мало, учитывая 5-и часовый 0-й архив.
У меня не очень быстрый стриммер (ему все таки уже 5 лет). А винтам всего
два года. Тем более, при перекачке передаются только данные, а в архив-0
включается все.
>> При меньшей разнице в
>> производительности серверов видимо более предпочтительным было бы
>> создавать все индексы во второй части.
>Странно, что ты все таки строил индексы, а потом грузил данные.
>Я понял, что это тормозов не вызывало, но как то нелогично :)
>Я бы над этим даже не думал...
Все благодаря лени, dbschema 7.31 выгружает схему базы именно в такой
последовательности:
Tables+Indexes;foreign keys;procedures;triggers
>> Возможные варианты повышения производительности:
>> 1. Почему-то на старом сервере абсолютно не использовался Read Ahead
>> (может он просто не работает для нелоггируемых баз ?).
>По моему, он преимущественно используется для чтения индексов, а в твоем
>случае они вряд ли использовались.
При обычной работе ixda-RA + idx-RA у меня всего процентов на 10 больше,
чем da-RA, так что объяснение не подходит. Так как, при загрузке da-RA как
был ноль, так и остался (хотя я мог, что-то перепутать, так как это
происходило когда ночь пятницы плавно перетекла в вечер воскресенья).
Regards, Igor.
Igor Zavgorodny
Sergey E. Volkov wrote:
>> Несмотря на предстоящее прекращение поддержки Solaris-a x86 я все таки
>Однако откуда дровишки ? Насколько я знаю они заявили, что
приостанавливают
>Solaris 9 для IA32 до выяснения 'рыночной ситуации', а восьмерку будут
>потдерживать в течение 7 лет.
Дрова были основаны именно на этом заявлении. Я почему-то был уверен в
цифре "2 года" и в том, что решение было окончательное. Сорока на хвосте
принесла мне благую infoworld-овскую весть, почти сразу как я запостил
мессагу, не иначе как знамение :-)). Так, что будем надеятся налучшее.
Хотя горячо любимый Informix для Solaris x86 многого не делает. Например,
утилитка dupchk для лечения страшного и ужасного #144428 в 7.31.UC7,
по-моему так и не вышла, SDK под него в свободном доступе не лежит и т.д.
и т.п.
>Что касается производительности, то под Linux она будет немного повыше,
Я так понимаю, имеется ввиду в однопроцессорном варианте? У меня их больше
(целых два :-). Если серьезно, сам тестов не ставил, но представители
разработчиков утверждают, что ими была получена 1.5 разница в скорости в
пользу Соляриса (правда, насколько я понял, на 4-ых процессорах, что
именно мерялось я не уточнял :-).
>чего однако
>никак нельзя сказать про надежность - ну просто нельзя сравнивать.
Без возвражений. Тем более, для меня она главное, по скорости у меня
теперь запас по прочности примерно на порядок.
>> "Hardware compatabile list", выбранной им OS. Впрочем Соляру x86 на
новый
>> продакшен сервер в 2002 году тоже наверняка никто не поставит :-).
>Почему ?
Я исходил из "цифры 2 года на поддержку". Ну и сложившийся у меня опыт
общения с "буржуинами" (правда они все достаточно специфичные, хотя и из
разных организаций), показывал, что люди в плане "основных" серверов
всегда выбирали RISC платформу.
>Поставь Solstice Disk Suite. ( Можно свободно скачать с Sun )
Спасибо, я думал, что он платный (like Veritas). Видимо, прийдется вся
опять переконфигурить :-).
Regards, Igor.
Serg Kovalenko
> Привет, Сергей.
>
> >Поставь Solstice Disk Suite. ( Можно свободно скачать с Sun )
> Спасибо, я думал, что он платный (like Veritas). Видимо, прийдется вся
> опять переконфигурить :-).
Не придется, ибо Solstice Disk Suite для 8 соляры имеет такое же ограничение
на кол-во слайсов.
Это исправлено в 9-ой соляре. Еще раз внимательно читаем все что видем на
www.sun.com
Sergey E. Volkov
"Serg Kovalenko" <s...@profix.kiev.ua> сообщил/сообщила в новостях следующее:
news:aa3ssb$qfn$1...@castle.profix.kiev.ua...
>
> "Igor Zavgorodny" <dau...@torba.com> wrote in message
> news:3cc54189$1@proxy...
> > Привет, Сергей.
> >
>
> > >Поставь Solstice Disk Suite. ( Можно свободно скачать с Sun )
> > Спасибо, я думал, что он платный (like Veritas). Видимо, прийдется вся
> > опять переконфигурить :-).
> Не придется, ибо Solstice Disk Suite для 8 соляры имеет такое же
ограничение
> на кол-во слайсов.
Geezzzz..... Придется однако .... ставим патчик 108693-06 и все OK ...
( кстати она - Solstice Disk Suite идет прямо с этим патчем )
Еще раз внимательно читаем все что видем ..... -:)
Serg Kovalenko
"Sergey E. Volkov" <sergey_...@hotmail.com> wrote in message
news:aa404t$v2l$1...@news.lucky.net...
>
> "Serg Kovalenko" <s...@profix.kiev.ua> сообщил/сообщила в новостях
следующее:
> news:aa3ssb$qfn$1...@castle.profix.kiev.ua...
> >
> > "Igor Zavgorodny" <dau...@torba.com> wrote in message
> > news:3cc54189$1@proxy...
> > > Привет, Сергей.
> > >
> >
> > > >Поставь Solstice Disk Suite. ( Можно свободно скачать с Sun )
> > > Спасибо, я думал, что он платный (like Veritas). Видимо, прийдется вся
> > > опять переконфигурить :-).
> > Не придется, ибо Solstice Disk Suite для 8 соляры имеет такое же
> ограничение
> > на кол-во слайсов.
>
> Geezzzz..... Придется однако .... ставим патчик 108693-06 и все OK ...
> ( кстати она - Solstice Disk Suite идет прямо с этим патчем )
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
The document or patch you are attempting to access is available to contract
customers only. You can obtain the patch from your local Solution Center.
North American customers can call 1-800-USA-4SUN.
?!
Sergey E. Volkov
>
> "Sergey E. Volkov" <sergey_...@hotmail.com> wrote in message
> news:aa404t$v2l$1...@news.lucky.net...
> >
> > "Serg Kovalenko" <s...@profix.kiev.ua> сообщил/сообщила в новостях
> следующее:
> > news:aa3ssb$qfn$1...@castle.profix.kiev.ua...
> > >
> > > "Igor Zavgorodny" <dau...@torba.com> wrote in message
> > > news:3cc54189$1@proxy...
> > > > Привет, Сергей.
> > > >
> > >
> > > > >Поставь Solstice Disk Suite. ( Можно свободно скачать с Sun )
> > > > Спасибо, я думал, что он платный (like Veritas). Видимо, прийдется
вся
> > > > опять переконфигурить :-).
> > > Не придется, ибо Solstice Disk Suite для 8 соляры имеет такое же
> > ограничение
> > > на кол-во слайсов.
> >
> > Geezzzz..... Придется однако .... ставим патчик 108693-06 и все OK ...
> > ( кстати она - Solstice Disk Suite идет прямо с этим патчем )
> глядим здесь:
> http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
> The document or patch you are attempting to access is available to
contract
> customers only. You can obtain the patch from your local Solution Center.
> North American customers can call 1-800-USA-4SUN.
Привет Серж,
Прошу прощения за неточность - должно быть 108694-06.
На страничке загрузки:
Download Solstice DiskSuite 4.2.1 with Patch 108694-06 (x86) ( 8.93 MB )
Serial Number(s):
Note: If no serial number appears, it's not required for this product.
Technical Support & Installation
Solstice DiskSuite 4.2.1 with
Patch 108694-06 (x86)
Igor Zavgorodny
>Прошу прощения за неточность - должно быть 108694-06.
108693 - это для Sparc.
Текущая его версия под x86 - это 108694-07. На Sun кстати - "Access denied". Но я думаю, найду. Спасибо.
Regards, Igor.
Eugene Nechayev
Я тут опять запаздываю с ответами, так что в основном буду любопытствовать.
;-)
"Igor Zavgorodny" <dau...@torba.com> wrote in message
news:3cc42964$1@proxy...
> Hi All.
> Я сейчас переношу небольшую базу (14 Гб) на новый сервер. В процессе
> миграции возникли некоторые вопросы, которые навернека встали перед
> многими здесь присутствуюшими.
>
> Исходные данные:
> 2xPProx200Mhz, 256 RAM, RAID-5 на 3-х 18.2Гб 7200 дисках, SCO 5.0.2; IDS
> 7.31UC5
> В эксплуатации 5 лет, заменены винты 2 года назад + 1.5 года назад
> миграциия IDS с 7.22 на 7.31.
> Архив нулевого уровня на ленту - 5.5 часов. Основные причины миграции -
> неудовлетворительное время подъема в случае краха, места по дискету
>
> Платформа.
> Тут сразу вспоминается фраза "наши реалии", сказанная Василием Шульженко о
> конфигурации, описанной Евгением Нечаевым всего то в июле 2001 года
>
:-).http://groups.google.com/groups?hl=uk&threadm=9js6qd%24ggd%241%40news.lu
cky.net&rnum=1&prev=/groups%3Fq%3Dukr.comp.dbms.informix%2BRAID%2B%25E4%25F0
%25F3%25E3%26hl%3Duk
Не скажи, просил два RAID'a (второй как hot backup первого) по три
контроллера на каждом, получил
один RAID и один контроллер, так что у всех свои реалии ;-)
>
> OS.
> К сожалению, RISC платформы, несмотря на серьезное снижение цен, все таки
> идут лесом. Поэтому выбирать приходится из Caldera, Solaris x86, Linux.
> Несмотря на предстоящее прекращение поддержки Solaris-a x86 я все таки
> остановился на нем .У меня нет времени на эксперименты с Linux, а
> поставщик прикладного софта пока не позиционирует его в качестве основной
> платформы. По поводу продукции Caldera, возможно она имеет определенное
> будующее, но я выбираю платформу сейчас, а через 5 лет посмотрим. Про M$
> как обычно либо ничего, либо только ... :-)
В принципе, я сторонник коммерческих *nix, так что твой выбор мне близок :)
>
> Железо.
> Понятно дело, что насмотревшись на конфигурацию имени Жени, я сидел на
> пальцах прикидывал свой бюджет, и обнаружил в нем возможность закупки
> "4-ых канального RAID". Впрочем, стоит учесть еще одну именно "нашу
> особенность". В буржуинщине никто никогда не купит железо, которого нет в
> "Hardware compatabile list", выбранной им OS. Впрочем Соляру x86 на новый
> продакшен сервер в 2002 году тоже наверняка никто не поставит :-).
Угу.
> Воспользовавшись услугами телеграфного агенства ОБС, я выяснил, что
> приобретаемое мною железо с Солярой справится и особых проблем за ним не
> замеченно (пара проблем все таки нашлась, но оказалась вполне преодолима).
> Основным недостатком оказалось, что Соляра не видела больше 7-логических
> дисков, сконфигурированных на RAIDe. (впрочем сам RAID-контролер может
> сделать их только 8-м). В результате имеем такую организацию:
>
> 1.2Гб ОЗУ, 2x1.26PIII, 4-ых канальный RAID 128Мб ОЗУ .....
>
> RAID-стойка на 14 дисков разбита на 6 логических дисков в 1-м RAID-е, +2
> винта в Hot Spair (запас как известно ж... не "трогает"):
Проблему с количеством логических дисков, я так понимаю, ты разрешил.
>
> 0-й диск - система
> 1-й диск - rootdbs
> 2-й диск - physical & logical logs
Ммм... не согласен. Или physical или logical logs имеет смысл вынести к
rootdbs, или же разбить logical logs
между 1-м и 2-м диском.
> 3-5 диски - на каждом по dbspac-у для данных
> Данные первоначально планировалось фрагментировать по ROUND ROBIN, но
> учитывая, что 9-ка имеет индексы DETACHED и в 9.3 судя по всему нет уже и
> workaround-а для некоторых из них (DEFAULT_ATTACH), т.е. индексы надо либо
> фрагментировать по условию, что конечно производительно, но трудоемко, тем
> более, что сервер планируется сделать с минимальными требованиями ко
> времени DBA на ближайшие 3 года. В связи с этим наверное будет round-robin
> на 2 dbspace для данных и отдельный dbspace под индексы. либо какое-нибудь
> совсем другое разбиение (соотношение данных к индексам у меня примерно
> 55/45).
В таком случае имеет смысл обратить внимание на stripping. Т.к. сделать
фрагментацию по индексам,
можно, но достаточно неудобно, а перегрузка indecies dbspaces очень и очень
возможна.
>
> Ну и венец творения - 4x18.2 Гб SCSI диска , не влезших в RAID -стойку, на
> каждом по 2Гб tempdbspace + партиции для ночных бекапов, DVD фильмов и
> т.д.
>
> IDS. 9.21.UC2
>
> Перенос данных:
> При таком раскладе оффициальных мигрейшен тулов - два (dbexport и HPL).
> Веру в dbexport для сколько нибудь больших объемов данных я утратил
> достаточно давно. Разбиратся с HPL или с myexport by Art.S.Kagel время
> традиционно не нашлось.
Нуу... с HPL ты все таки разобрался ;-) не так страшен черт, как его рисуют,
особенно когда прижмет ;-)
> По этому было опробованно решение "в лоб", т.е.
> без потерь времени на выгрузку в файлы:
>
> 1. На старом сервере добавляем новый сервер в host.equiv
> 2. На новом сервере старый сервер в sqlhosts.
> 3. База на старом сервере переводится в режим "no logging".
> 4. dbschema делится на две части, 1-я создание таблиц и индексов, 2-я
> создание foreign-констрейнтов, процедур, триггеров.
> 5. Создается первая часть БД.
> 6. Переливаются данные запросами типа "insert into table select * from
> database@oldserver:table"
> 7. Выполняется вторая часть скрипта.
Тут в принципе добавить нечего (если не трогать HPL), за исключением, что
если между
серверами не оптика, то сетку можно перегрузить, если заниматься загрузкой
параллельно, но
обьем у тебя был не большой, так что...
[мыши]
>
> P.S. Любые комментарии и вопросы приветствуются.
На какой дисковой и логической конфигурации ты остановился ?
onstat -g iof и onstat -d приветствуются :)
Igor Zavgorodny
любопытствовать.
>Проблему с количеством логических дисков, я так понимаю, ты разрешил.
Ну она как бы осталась, но я с ней смирился. У меня 6 логических дисков на
RAID-e, 4-логических винта под tempdbs, на внутреннем контролере. Итого
при двух запасных каналах на RAID-e, я могу добавить только один
логический винт :-(. 8-й Соляра так и не видит. От Software Partion имени
Sun-a пришлось отказатся, так как опять таки, если с ними будет проблема в
мое отсутствие, помочь с ними будет не кому :-(.
Впрочем, есть надежда, что 90Гб под данные мне года на 3 хватит с избытком
(сейчас при всех натяжках у меня за юзанно 21Гб, с данными за 5 лет,
впрочем с каждым годом они растут быстрее и быстрее :-).
>> 0-й диск - система
>> 1-й диск - rootdbs
>> 2-й диск - physical & logical logs
>Ммм... не согласен. Или physical или logical logs имеет смысл вынести к
>rootdbs, или же разбить logical logs
>между 1-м и 2-м диском.
Уже :-)
0-й система
1-й root
2-й phys
3-й log
4-й "маленькие" справочники, которые не могу фрагментировать из-за
особенностей софта.
1,2,3,5 - ROUND ROBIN основных данных
1,2,3,4,5 - индексные чанки (к "маленьким" справочникам на 5-ом диске,
остальные как получится).
>>В таком случае имеет смысл обратить внимание на stripping. Т.к. сделать
>>фрагментацию по индексам,
>>можно, но достаточно неудобно, а перегрузка indecies dbspaces очень и
очень
>>возможна.
Угу, мне из-за этого пришлось перепахать две процедуры, так как изначально
в список "маленьких справочников" попали несколько десятков табличек,
которые ежедневно пересоздаются (с ними впрочем и идет основная работа).
>Нуу... с HPL ты все таки разобрался ;-) не так страшен черт, как его
рисуют,
>особенно когда прижмет ;-)
Я не до конца разобрался, как загружать с его помощью BLOB-ы я так и не
осознал. Причем сволота, в лог пишет, что все Ок, а загружают пустоту.
Впрочем, маленькие таблички все равно быстрее грузятся dbload-ом, а
"blobные" у меня как раз из таких.
>Тут в принципе добавить нечего (если не трогать HPL), за исключением, что
>если между серверами не оптика, то сетку можно перегрузить, если
заниматься загрузкой
>параллельно, но обьем у тебя был не большой, так что...
Как раз параллельно, при этой схеме не получится - базу надо в "no
logging" переводить. Сервера у меня сидят на одном 100Мбитном Switche, так
что тут проблем нет. Ну и все равно я взялся за HPL ;-).
>На какой дисковой и логической конфигурации ты остановился ?
>onstat -g iof и onstat -d приветствуются :)
С iof прийдется подождать, юзера туда пойдут только в понедельник, а моя
эммуляции дня учитывает только главную часть работы системы, кроме того
она не сохранилась и повторять ее напряжно. По памяти, тонких мест у меня
получилось два, это temp-ы, но это скорее зависит от моего метода
эмуляции, в итоге заставившую одну из задач, каждые две минуты выполнять
весьма серьезную выборку, что в реальной работе мало возможно. Ну и 2-е,
это естественно индексы, но там все терпимо. Кроме того, проблемы эти не
всплывают при работе критически важных для меня задач.
Regards, Igor.
Informix Dynamic Server 2000 Version 9.21.UC2 -- On-Line -- Up
00:41:38 -- 698368 Kbytes
Dbspaces
address number flags fchunk nchunks flags owner name
6b1187d0 1 0x1 1 1 N informix rootdbs
6ba5ae28 2 0x1 2 1 N informix phlog
6ba5b018 3 0x1 3 1 N informix lglog
6ba5b160 4 0x1 4 4 N informix data1
6ba5b2a8 5 0x1 5 4 N informix data2
6ba5b3f0 6 0x1 6 4 N informix data3
6ba5b538 7 0x1 7 4 N informix data4
6ba5b680 8 0x1 8 4 N informix data5
6ba5b7c8 9 0x1 9 11 N informix idx
6ba5b910 10 0x2001 10 1 N T informix t0
6ba5ba58 11 0x2001 11 1 N T informix t1
6ba5bba0 12 0x2001 12 1 N T informix t2
6ba5bce8 13 0x2001 13 1 N T informix t3
13 active, 2047 maximum
Chunks
address chk/dbs offset size free bpages flags pathname
6b118918 1 1 0 1024000 1020320 PO-
/usr/informix/data/d1s0
6b148830 2 2 0 448056 198003 PO-
/usr/informix/data/d2s11
6b148998 3 3 0 1024000 459 PO-
/usr/informix/data/d3s0
6b148b00 4 4 0 1024000 88832 PO-
/usr/informix/data/d1s1
6b148c68 5 5 0 1024000 88832 PO-
/usr/informix/data/d2s1
6b148dd0 6 6 0 1024000 88840 PO-
/usr/informix/data/d3s1
6ba58018 7 7 0 1024000 2754 PO-
/usr/informix/data/d4s1
6ba58180 8 8 0 1024000 88856 PO-
/usr/informix/data/d5s1
6ba582e8 9 9 0 1024000 193 PO-
/usr/informix/data/d5s0
6ba58450 10 10 0 1024000 1023619 PO-
/usr/informix/data/t0s0
6ba585b8 11 11 0 1024000 1023549 PO-
/usr/informix/data/t1s0
6ba58720 12 12 0 1024000 1023715 PO-
/usr/informix/data/t2s0
6ba58888 13 13 0 1024000 1023690 PO-
/usr/informix/data/t3s0
6ba589f0 14 9 0 448056 383 PO-
/usr/informix/data/d1s11
6ba58b58 15 9 0 1024000 538398 PO-
/usr/informix/data/d2s0
6ba58cc0 16 9 0 448056 448053 PO-
/usr/informix/data/d3s11
6ba58e28 17 9 0 448056 448053 PO-
/usr/informix/data/d4s11
6ba59018 18 9 0 448056 448053 PO-
/usr/informix/data/d5s11
6ba59180 19 9 0 1024000 1023997 PO-
/usr/informix/data/d1s3
6ba592e8 20 9 0 1024000 1023997 PO-
/usr/informix/data/d2s3
6ba59450 21 9 0 1024000 1023997 PO-
/usr/informix/data/d3s3
6ba595b8 22 9 0 1024000 1023997 PO-
/usr/informix/data/d4s3
6ba59720 23 9 0 1024000 1023997 PO-
/usr/informix/data/d5s3
6ba59888 24 4 0 1024000 673997 PO-
/usr/informix/data/d1s4
6ba599f0 25 4 0 1024000 1023997 PO-
/usr/informix/data/d1s5
6ba59b58 26 4 0 1024000 1023997 PO-
/usr/informix/data/d1s6
6ba59cc0 27 5 0 1024000 673997 PO-
/usr/informix/data/d2s4
6ba59e28 28 5 0 1024000 1023997 PO-
/usr/informix/data/d2s5
6ba5a018 29 5 0 1024000 1023997 PO-
/usr/informix/data/d2s6
6ba5a180 30 6 0 1024000 673997 PO-
/usr/informix/data/d3s4
6ba5a2e8 31 6 0 1024000 1023997 PO-
/usr/informix/data/d3s5
6ba5a450 32 6 0 1024000 1023997 PO-
/usr/informix/data/d3s6
6ba5a5b8 33 7 0 1024000 4 PO-
/usr/informix/data/d4s4
6ba5a720 34 7 0 1024000 824334 PO-
/usr/informix/data/d4s5
6ba5a888 35 7 0 1024000 1023997 PO-
/usr/informix/data/d4s6
6ba5a9f0 36 8 0 1024000 673997 PO-
/usr/informix/data/d5s4
6ba5ab58 37 8 0 1024000 1023997 PO-
/usr/informix/data/d5s5
6ba5acc0 38 8 0 1024000 1023997 PO-
/usr/informix/data/d5s6
38 active, 2047 maximum
Eugene Nechayev
> >Я тут опять запаздываю с ответами, так что в основном буду
> любопытствовать.
> Будь ласка :-).
'На дворе идет дождь, а у нас идет концерт(c)'
>
> >Проблему с количеством логических дисков, я так понимаю, ты разрешил.
> Ну она как бы осталась, но я с ней смирился. У меня 6 логических дисков на
> RAID-e, 4-логических винта под tempdbs, на внутреннем контролере. Итого
> при двух запасных каналах на RAID-e, я могу добавить только один
> логический винт :-(. 8-й Соляра так и не видит. От Software Partion имени
> Sun-a пришлось отказатся, так как опять таки, если с ними будет проблема в
> мое отсутствие, помочь с ними будет не кому :-(.
> Впрочем, есть надежда, что 90Гб под данные мне года на 3 хватит с избытком
> (сейчас при всех натяжках у меня за юзанно 21Гб, с данными за 5 лет,
> впрочем с каждым годом они растут быстрее и быстрее :-).
А какой RAID, я имею в виду номер ? 1,01,10,5 ?
> 0-й система
> 1-й root
> 2-й phys
> 3-й log
A log разложить не хочешь между двумя дисками ? root все равно будет
простаивать.
> 4-й "маленькие" справочники, которые не могу фрагментировать из-за
> особенностей софта.
> 1,2,3,5 - ROUND ROBIN основных данных
Т.е. stripping ты включать не стал. А почему ? Одна из задач была 'минимум
DBA'
> 1,2,3,4,5 - индексные чанки (к "маленьким" справочникам на 5-ом диске,
> остальные как получится).
Как ты организовал индексы ? FRAGMENT BY EXPRESSION или как то иначе ?
Т.е. грубо говоря как ты разложил их по 1,2,3,4,5 что бы хранить баланс по
заполнению ?
> Как раз параллельно, при этой схеме не получится - базу надо в "no
> logging" переводить.
Ммм... ondblog не пробовал ?
>onstat -d
Зеркала ? Не хочешь или не можешь сделать ?
Какую recovery strategy ты выбрал ?
Без зеркал и с ROUND ROBIN, ты похоже можешь восстановиться только с бекапа,
время восстановления тебя устраивает ?
Что используется для бекапа ?
PDQ используется ?
Мда..., что то много вопросов получилось.
Евгений
Igor Zavgorodny
>А какой RAID, я имею в виду номер ? 1,01,10,5 ?
12-ти, делаем шесть 1-ых Raid-ов. +4 диска на отдельном контролере
tempdbs-ы.
>> 0-й система
>> 1-й root
>> 2-й phys
>> 3-й log
>A log разложить не хочешь между двумя дисками ?
>root все равно будет простаивать.
Не понял, physical или logical ? Насколько я понимаю, physical кроме как
mirrorингом не разложишь, а дробить logical на разные диски получится
как-то странновато, т.е. один лог на одном диске, следующий на другом,
третий опять на первом? Если ты имеел ввиду отделить physical от logical,
так я и отделил 2-й phys, 3-й log.
На root-овом у меня живут и данные и индексы, если окажется, что диск не
достаточно нагружен, у меня там есть резерв для создания еще нескольких
чанков.
>> 1,2,3,5 - ROUND ROBIN основных данных
>Т.е. stripping ты включать не стал. А почему ? Одна из задач была 'минимум
>DBA'
мммм, а что ты имеешь ввиду по "stripping" ? Я грешным делом, думал, что
имеется ввиду RAID-овский, он у меня выставлен на максимум - 64к.
>> 1,2,3,4,5 - индексные чанки (к "маленьким" справочникам на 5-ом диске,
>> остальные как получится).
>Как ты организовал индексы ? FRAGMENT BY EXPRESSION или как то иначе ?
>Т.е. грубо говоря как ты разложил их по 1,2,3,4,5 что бы хранить баланс по
>заполнению ?
Подходящих Expression мне будет сложновато, вернее они есть, но они не
совместимы с "задачей минимум DBA". Поэтому сделано было следующим образом
- просто расшвыряны чанки индексного dbspac-e по разным дискам (я onstat
-d приводил), Я хотел попробовать сделать для индексов кучов чанков
размером где-нибудь по 50Мб и посмотреть, что из этого выйдет. Впрочем,
задачи, критичные по быстродействию, у меня используют таблицы, которые
ежедневно пересоздаются, так что поменять и выбрать более интересную схему
всегда можно.
>> Как раз параллельно, при этой схеме не получится - базу надо в "no
>> logging" переводить.
>Ммм... ondblog не пробовал ?
Архив 0, все равно после него прийдется делать, если вдруг назад захочется
вернутся. Впрочем, назад мне дороги уже нет. Места на старом сервере еще
на неделю не хватит, а новый винт туда не добавить.
>>onstat -d
>Зеркала ? Не хочешь или не можешь сделать ?
Честно говоря, смысла не вижу. Зеркалировать все - слишком жирно (места на
5 лет не хватит), а работать без любой части данных я не смогу.
>Какую recovery strategy ты выбрал ?
>Без зеркал и с ROUND ROBIN, ты похоже можешь восстановиться только с
бекапа,
>время восстановления тебя устраивает ?
>Что используется для бекапа ?
6-ленточный Autoloader DDS4 (40Гб с компрессией на одной ленте). Время
восстановления level0 - 33 минуты.
Время на освоение onbar-a не хватило, так что пока ontape-изирую по
маленьку.
В качестве дополнительной фичи, делается еженочное создание "маленькой"
базы на бекапном сервере. Учитывая, что изменение данных у меня
производится роботами на основании файликов, то я могу раскрутится от этой
базы и файликов (взять их есть откуда) за приемлимое время.
>PDQ используется ?
Только при загрузке данных в момент построения индексов. У меня сходу
всплыл как минимум один запрос, который с PDQ выполняется очень не
стабильно, выдается error -211 ISAM -103 при запуске не на sysmaster-e.
SELECT sysmaster:sysopendb.odb_isolation
FROM sysmaster:sysopendb
WHERE (DBINFO('sessionid') = sysmaster:sysopendb.odb_sessionid) AND
(sysmaster:sysopendb.odb_iscurrent = "Y");
Regards, Igor.