> Если талица не создается заново каждый раз, а лишь > дополняется данными, можно попробовать уменьшить заполнение > страниц. Это поможет снизить расходы на выделение страниц > БД, но также может существенно повлиять на увеличение > размеров БД в сторону увеличения. Пару дней назад мы разбили таблицу на не несколько. Рабочая - небольшая там данные только за пару месяцев. Но и то - размер MDF ~ 180 Gbt. Из них преаллокировано и заполнена половина.
Как увеличить скорость 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
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
