|
|
|
dbexport
|
|||
|---|---|---|---|
|
#18+
День Добрый. Подскажите, пожалуйста, кто знает. Я первый раз делаю dbimport базы данных. Сама база в архиве tar.gz весит около 700 Мб. Скрипт, который занимается загрузкой базы, сначала, например, создает таблицу, а затем создает т.н. уникальные индексы. Так вот, на одной из таблиц скрипт оснатавливается, как мне кажется, на очень длительное время на пункте создания этих индексов. Винчестер шуршит, компутер становится очень инертен к запросам. Например вчера, я ждал часа 4, пока скрипт наконец создаст индексы для этой таблицы, но так и не дождался. Ночью, к сожалению, был длительный сбой электричества и результатов я не знаю. Вопрос вот в чем - нормально ли это, такая длительная задержка при создании этик уникальных индексов? IDS 7.30UC10. Linux RedHat 9.0. 256 Мб ОЗУ. Проц. PIII 600 МГц. HDD Samsung 40 Gb, ATA. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 16:33 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
Таблица большая на которой индексы строятся? Если экспорт занимает в сжатом виде 700Мб то в нормальном виде он будет больше минимум раза в 3, текст ведь очень хорошо жмется. Перед началом импорта установи в консоли, откуда запускаешь dbimport перемернyю PDQPRIORITY=100, может индексы будут строится быстрее. Посмотри также что стоит в DBSPACETEMP в onconfig. Или в этой же консоли установи путь для временных файлов сортировок PSORT_DBTEMP. Ну а вообще покажи onconfig. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 17:23 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
Индекс кластеризованный? ----------------------------------------------------------------------------------------------------------------------------------------- нужно делать то что нужно, а то что не нужно -- делать не нужно (перефразируя В-Пуха). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 17:24 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
workaholik...Сама база в архиве tar.gz весит около 700 Мб... Вопрос вот в чем - нормально ли это, такая длительная задержка при создании этик уникальных индексов? IDS 7.30UC10. Linux RedHat 9.0. 256 Мб ОЗУ. Проц. PIII 600 МГц. HDD Samsung 40 Gb, ATA. Для такого слабого железа и размера БД, думаю, это нормально. Кстати, чем гадать абстрактно, ты бы мог посмотреть в тот самый скрипт и увидеть какого размера эта таблица (кол-во строк и длина строки) и кол-во индексов по ней, которые могут быть не только уникальные, но и других видов (они явно не указываются, а создаются автоматически при указании констрейнтов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 19:22 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
Оставлю опять на ночь. А утром, если ничего не сдвинется, буду делать, как советовали товарищи выше. Просто в данный момент мне до машины не достучаться ;о( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 20:14 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
Пару лет назад у нас база по двое суток грузлась (Sun был слабенький). Для ускорения процесса на время загрузки можно снимать constraint-ы (set constraint disable (или defert???)). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 17:21 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
bk0010Для ускорения процесса на время загрузки можно снимать constraint-ы (set constraint disable (или defert???)). dbimport сначала создает таблицы и грузит данные и только потом создает индексы и определяет констрейнты с автоматическими индексами. Т.е. загрузка данных с включенными констрейнтами не производится. Так что не очень понятно, когда это вы умудрялись выключать констрейнты. А ведь их потом и включать то надо :) Может речь у вас шла о dbload или другой дозагрузке данных, но мы то говорим о dbimport ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 18:32 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
Полез проверил. Вы правы. dbimport грузил только структуру базы, а данные заполнялись другим скриптом из соседней базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 12:29 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
Решил спросить в этой же теме. Есть база в одной кодировке. Переношу на новый сервер в другой кодировке. dbimport естественно ругается на формат даты. Наверняка та же проблема с дататаймом. Как в данной ситуации поступить? Базу надо создать новую в другой (правильной ) кодировке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 19:04 |
|
||
|
dbexport
|
|||
|---|---|---|---|
|
#18+
Помните, что в самой БД даты (и др. зависимые от локали данные) хранятся в независимом формате и только от установленной локали клиента они получают свой вид. Поступить можно двумя способами. 1. На время выгрузки старой БД установить параметры локали, которые будут подходить для новой БД при загрузке. 2. Если БД уже выгружена, то только на момент загрузки установить нужные параметры локали. например, БД была с локалью ru_ru.1251 и уже выгружена с такой же локалью у клиента и доп.параметрами, обычно используемыми для работы с такой БД Код: plaintext 1. Тогда только на момент загрузки БД в системном окружении консольного окна, где будет выполняться dbimport, нужно установить такие же значения GL_DATE и DBMONEY, что были при выгрузке. А дальше при работе клиента использовать свои значения или значения по умолчанию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 21:56 |
|
||
|
|
start [/forum/topic.php?fid=44&msg=33739904&tid=1608664]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 210ms |
| total: | 334ms |
| 0 / 0 |
