> Если в существующую таблицу БД интенсивно вставляются > строки - имеет смысл уменьшить процент заполнения страниц > Если же каждый раз таблицы создаются заново - имеет смысл > увеличить процент заполнения страниц для более плотного
Если уж база на 180 гиг, то настройками сильного прироста скорости не достичь.
180 гиг это не 180 мег и тем более не 180 кил. Любая прокачка/обработка гигов не будет слишком быстра.
Если индексы создаются достаточно долго, значит они большие. Не дай бог это какое-нибудь ключевое поле. На каждую запись будет происходить поиск уже существующего индекса, плюс создание нового. Не имеет ли смысл отказаться от индексации?
Как увеличить скорость insert для Microsoft SQL Server 2000.23.11.06 02:50 Автор: void <Grebnev Valery> Статус: Elderman Отредактировано 23.11.06 02:51 Количество правок: 1
Каждый день, все данные из таблиц Table на нескольких MySQL серверов должны быть скопированы в одну таблицу TableBackup на Microsoft SQL Server 2000.
В принципе, суммарное число записей для копирования невелико ~2 000 000 - 3 000 000.
Пока база на Microsoft SQL Server 2000 невелика, всё идёт сносно. При размере базы (где TableBackup) порядка ~ 300 Gbt, копирование занимает ~ 7-9 часов, что критично.
Можно ли на Microsoft SQL Server каким -то образом отключить логи на время этих операций, или ещё что...
Как увеличить скорость копирования???
Спасибо.
Вроде бы разрешилось.26.11.06 20:57 Автор: void <Grebnev Valery> Статус: Elderman
Дак если не ошибаюсь, эта "фича" была еще в SQL 6.0 (или даже раньше в первых M$-релизах DB2), причем была обертка даже в Delphi BDE-desktop и в виде примеров к самому SQL-серверу на С. На самом деле, прежде всего, просто избавляет от лишних накладных API-расходов, а начиная (если не ошибаюсь) с SQL 2000 экономит место в журнале транзакций.
Знание BulkCopy входит в тесты SQL-essential. Способ дропнуть индексы кажется был в advanced.
Впрочем, я с этим возился очень давно, лет 6-8 назад, могу ошибаться
B .NET v. 1.0 этого класса, SQLBulkCopy, не было.27.11.06 00:55 Автор: void <Grebnev Valery> Статус: Elderman
Если талица не создается заново каждый раз, а лишь дополняется данными, можно попробовать уменьшить заполнение страниц. Это поможет снизить расходы на выделение страниц БД, но также может существенно повлиять на увеличение размеров БД в сторону увеличения.
Пару дней назад мы разбили таблицу на не несколько. Рабочая...28.11.06 04:50 Автор: void <Grebnev Valery> Статус: Elderman
> Если талица не создается заново каждый раз, а лишь > дополняется данными, можно попробовать уменьшить заполнение > страниц. Это поможет снизить расходы на выделение страниц > БД, но также может существенно повлиять на увеличение > размеров БД в сторону увеличения. Пару дней назад мы разбили таблицу на не несколько. Рабочая - небольшая там данные только за пару месяцев. Но и то - размер MDF ~ 180 Gbt. Из них преаллокировано и заполнена половина.
Значит у вас эти таблицы создаются каждый раз заново? [upd]28.11.06 12:27 Автор: Den <Денис Т.> Статус: The Elderman Отредактировано 28.11.06 12:31 Количество правок: 1
Если в существующую таблицу БД интенсивно вставляются строки - имеет смысл уменьшить процент заполнения страниц для увеличения скорости добавления записей.
Если же каждый раз таблицы создаются заново - имеет смысл увеличить процент заполнения страниц для более плотного размещения записей, что может существенно уменьшить размер БД и даже увеличить скорость чтения данных из таблиц.
Если уж база на 180 гиг, то настройками сильного прироста...28.11.06 15:28 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
> Если в существующую таблицу БД интенсивно вставляются > строки - имеет смысл уменьшить процент заполнения страниц > Если же каждый раз таблицы создаются заново - имеет смысл > увеличить процент заполнения страниц для более плотного
Если уж база на 180 гиг, то настройками сильного прироста скорости не достичь.
180 гиг это не 180 мег и тем более не 180 кил. Любая прокачка/обработка гигов не будет слишком быстра.
Если индексы создаются достаточно долго, значит они большие. Не дай бог это какое-нибудь ключевое поле. На каждую запись будет происходить поиск уже существующего индекса, плюс создание нового. Не имеет ли смысл отказаться от индексации?
Отказ от индексов позволяет делать туже работу раз в 10...29.11.06 03:03 Автор: void <Grebnev Valery> Статус: Elderman
> > Если в существующую таблицу БД интенсивно вставляются > > строки - имеет смысл уменьшить процент заполнения > страниц > > Если же каждый раз таблицы создаются заново - имеет > смысл > > увеличить процент заполнения страниц для более > плотного > > Если уж база на 180 гиг, то настройками сильного прироста > скорости не достичь. > 180 гиг это не 180 мег и тем более не 180 кил. Любая > прокачка/обработка гигов не будет слишком быстра. > Если индексы создаются достаточно долго, значит они > большие. Не дай бог это какое-нибудь ключевое поле. На > каждую запись будет происходить поиск уже существующего > индекса, плюс создание нового. Не имеет ли смысл отказаться > от индексации? Отказ от индексов позволяет делать туже работу раз в 10 бысрее (я проверил). Оставлю один, что нужен мне, и может ещё попросят один.
Кроме способа предложеным "ЗлымШаманом" и если жестко привязан к TableBackup имхо никак.23.11.06 08:54 Автор: [cb] Статус: Member
Если не привязан к TableBackup - можешь сделать несколько таблиц (каждая привязана к определенному MySQL серверу) и реплицировать их.
Тебе TableBackup для чего нужна?
regulation требует.Когда "закрывается" день, данные со всех...24.11.06 03:01 Автор: void <Grebnev Valery> Статус: Elderman
> Если не привязан к TableBackup - можешь сделать несколько > таблиц (каждая привязана к определенному MySQL серверу) и > реплицировать их. > Тебе TableBackup для чего нужна? regulation требует.Когда "закрывается" день, данные со всех серверов должны быть переданы в одну таблицу. Там данные хранятся несколько лет. Иногда люди делают вид, что работают с этими данными.
Можно эту одну большую таблицу разбить на несколько...24.11.06 10:08 Автор: ZloyShaman <ZloyShaman> Статус: Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
