|
|
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
Таблица большая 24 миллиона записей традиционно я переносил до сих пор dbload'ом но тут чувствую времени не хватит. Присоветуйте не пользовался ли кто для этих целей альтер фрагментом? Очень уж на нее ссылок много. Хочется чтоб без удаления таблицы. (типа мечта идиота) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2005, 19:48 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
альтер-фрагмент как раз по этим делам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2005, 20:34 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
а как насчет размера таблицы? onload не быстрее будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2005, 20:44 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
вопросы более конкретные 1 после выполнения альтер фрагмент с таким условием, что все записи окажутся в новом дбспэйсе, в старом чанки освободятся ? (сомневаюсь) 2 где останутся индексы? дело в том, что мне надо полностью освободить старое пространство. если индексы останутся в старом, то ничего не приходит в голову кроме их пересоздания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2005, 20:52 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
ага оказывается есть специальная олция ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2005, 00:21 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
Напиши потом, пожалуйста, сколько будет длиться перенос 24млн. строк (и сколько это в Мб) с одного пространства в другое и какая физическая скорость копирования с винта - интересует, насколько скорость переноса будет близка к физической скорости копирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2005, 12:01 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
во вчерашнем ночном эксперименте переносилась таблица 5 с лишним миллионов записей. onstat -d показал примерно 2 с половиной гига занятого пространства. Все пространства и темп и логдбспэйс и рабочие находились на одном винте. винт FC машина SUN Blade 1000 2CPU ULTRASPARC 3 750 Мгц перенос происходил 31 минуту. Журнализация естественно была выключена. про результаты на рабочей системе позже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2005, 15:07 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
Я думаю, что не лишне было бы указать row size. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2005, 19:53 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
{ TABLE "informix".logreesdoc row size = 400 number of columns = 39 index size = 186 } ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 02:26 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
Использовали alter fregment несколько раз для переноса таблиц между дбспэйсами (журналирование базы не выключали поскольку в это время там работали другие пользователи). При выполнении alter frament на больших таблицах нужно обязательно учитывать что может возникнуть длинная транзакция, поэтому перед этим желательно сделать бэкап. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 08:59 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
cprво вчерашнем ночном эксперименте переносилась таблица 5 с лишним миллионов записей. onstat -d показал примерно 2 с половиной гига занятого пространства. Все пространства и темп и логдбспэйс и рабочие находились на одном винте. винт FC машина SUN Blade 1000 2CPU ULTRASPARC 3 750 Мгц перенос происходил 31 минуту. Скорость, примерно, 1,5М/сек и хотя я не знаю о скорости винтов, но , мне кажется, медленновато (даже с учетом, что все было на одном винте и среднюю скорость можно удвоить). К тому же, логирование было выключено cpr Журнализация естественно была выключена. Кстати, а если сервер упадет в процессе переноса? Скорее всего, чанки будут в дауне ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 13:14 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
У меня тут мелькнула идея, но она хорошо реализуема только в том случае, если эта большая таблица занимает отдельное ДБ-пространство. Тогда я бы предложил создать зеркало, спокойно подождать даже не прерывая работы, пока оно синхронизируется с первичным пространством, а затем выключить первичное пространство, разорвав зеркало. Т.е. типичная операция по горячей замене диска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 13:18 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
во время выполнения альтер фрагмент, чтения из пространства источника выполняется примерно со скоростью, доходящей до 30 метров в секунду. При этом некоторая часть данных резервируется в исходном дбспэйсе. Запись идет со скоростью около 4 мегабайт в секунду. К тому же судя по характеру обмена данными при завершении переноса перестраиваются индексы, а это само по себе не быстро. С зеркалом номер не пройдет, возможности нет тк зеркало уже на уровне соляриса раз, а два перенос будет происходить на винт с другой структурой дбпространств, номысль интересная. Кстати вот запись идет не быстрее 4-х метров в секунду и все. Наш рут только руками разводит. Но правда запись идет через механизмы очистки буферов LRU, так что она в принципе должна быть медленнее чем физические возможности винта. Но вот чтоб настолько... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 19:30 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
cprво время выполнения альтер фрагмент, чтения из пространства источника выполняется примерно со скоростью, доходящей до 30 метров в секунду. Кстати вот запись идет не быстрее 4-х метров в секунду и все. Наш рут только руками разводит. Но правда запись идет через механизмы очистки буферов LRU, так что она в принципе должна быть медленнее чем физические возможности винта. Но вот чтоб настолько... Совершенно аналогичная картина. Физическая скорость (по dd) - 20 метров в секунду, логическая при чтении onunload - 8 метров в секунду, логическая при записи onload - 2 метра в секунду. Это я вчера четырёхснебольшимгиговую таблицу на другой сервер оттаскивал, после замены на ём всего на свете, включая диски. Заодно поразглядывал iostat. Да. Чуть не забыл. Логическое чтение ontape - 12 метров в секунду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 10:18 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
Ilya Kulagin cprво время выполнения альтер фрагмент, чтения из пространства источника выполняется примерно со скоростью, доходящей до 30 метров в секунду. Кстати вот запись идет не быстрее 4-х метров в секунду и все. Наш рут только руками разводит. Но правда запись идет через механизмы очистки буферов LRU, так что она в принципе должна быть медленнее чем физические возможности винта. Но вот чтоб настолько... Совершенно аналогичная картина. Физическая скорость (по dd) - 20 метров в секунду, логическая при чтении onunload - 8 метров в секунду, логическая при записи onload - 2 метра в секунду. Да. Чуть не забыл. Логическое чтение ontape - 12 метров в секунду. Вот и меня смущает сильно большая разница при чтении и записи... А достаточно было очистителей (cleaners) и KAIO на эти операции? Странно, почему onunload и ontape так отличаются скоростью чтения - обе утилиты читают двоичными страницами без всяких преобразований. Может потому, что 1-я написана индусами ? ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 11:50 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
vasilisСтранно, почему onunload и ontape так отличаются скоростью чтения - обе утилиты читают двоичными страницами без всяких преобразований. Может потому, что 1-я написана индусами ? ;)) Думаю, что у onunload все таки работы побольше будет - искать очередной экстент таблицы, принадлежащей базе, и т.п. А ontape тупо сканирует страницы чанков, просматривая только их заголовок. И либо пишет, либо нет. Да и разница-то всего в 1,5 раза :) Вот один индус есть, очень хороший: http://www.kernelthread.com/ Так вот (он, сечас, вроде в IBM работает), судя по тому, что он пишет и сделал, он один "уделал" бы всех нынешних разработчиков Informix 10.0 вместе взятых... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 15:45 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
Кстати при переносе alter fragment'ом пару раз прерывал выполнение запроса и все оставалось как было без проблем. А вот сервак валить мне не дали ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 16:14 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
cprКстати при переносе alter fragment'ом пару раз прерывал выполнение запроса и все оставалось как было без проблем. Тут непонятно - "все оставалось как было без проблем", т.е. все вернулось в исходное состояние (и это без поддержки транзакций) ? Или было промежуточное состояние, когда часть таблицы была в одном пространстве, а часть в другом, после которого повторное выполнение alter fragment просто продолжало работу ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 18:02 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
Все вернулось в исходное состояние, при выключенной журнализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 18:18 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
vasilis Странно, почему onunload и ontape так отличаются скоростью чтения Ну не так уж и сильно они отличаются. Особенно, если учесть, что ontape я глядел на новом сервере, "пустом", а onunload, - на старом, который в это время обслуживал народ. А вот чем onload занимается, мне даже интересно стало. Сегодня очередную таблицу потащил, mpstat показывает дословно: CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 424 1836 434 2015 0 297 36 0 2905 5 5 0 90 1 2 0 300 1140 4 2168 0 295 35 0 3184 4 6 0 90 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 224 1778 411 1609 5 284 47 0 2378 6 5 0 89 1 0 0 450 973 4 2303 16 287 46 0 2998 4 5 0 90 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 254 2543 714 1097 18 207 34 0 1178 6 3 0 91 1 0 0 1173 1058 6 2005 6 205 30 0 1389 4 6 0 89 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 504 4354 1099 971 15 113 19 0 580 3 3 0 93 1 0 0 2611 1472 3 2039 10 113 16 0 684 3 8 0 88 и так далее. То бишь, 90% idle time и iowait=0. Буду onstat пристально разглядывать. Кажется, ждёт меня где-то сюрприз в виде взаимной блокировки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 19:29 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
cprВсе вернулось в исходное состояние, при выключенной журнализации. Вот ведь умный сервер :) На самом деле, внутренняя транзакция все же была, она всегда есть независимо от режима логирования БД при некоторых операциях сервера, типа выделение экстента для табличного пространства, добавление чанка и т.п. Похоже, что и alter fragment тоже входит в эту группу, что естественно, не может не радовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2005, 15:24 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
vasilis cprВсе вернулось в исходное состояние, при выключенной журнализации. Вот ведь умный сервер :) :) Умный сервер просто очищает экстенты после того как перетащит. А вот умный волум менеджер аиксовый умеет перетаскивать волумы с одного диска на другой не блокируя чтение и запись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2005, 09:19 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
По вопросу медленной записи: А где у вас физлог? На том же устройстве? 2cpr: У тебя файлы или рау? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2005, 09:24 |
|
||
|
перенос таблицы в другой dbspace
|
|||
|---|---|---|---|
|
#18+
raw device естественно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2005, 22:37 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=32939799&tid=1609082]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 218ms |
| total: | 385ms |

| 0 / 0 |
