Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | |
Отказ от индексов позволяет делать туже работу раз в 10... 29.11.06 03:03 Число просмотров: 2979
Автор: void <Grebnev Valery> Статус: Elderman
|
> > Если в существующую таблицу БД интенсивно вставляются
> > строки - имеет смысл уменьшить процент заполнения
> страниц
> > Если же каждый раз таблицы создаются заново - имеет
> смысл
> > увеличить процент заполнения страниц для более
> плотного
>
> Если уж база на 180 гиг, то настройками сильного прироста
> скорости не достичь.
> 180 гиг это не 180 мег и тем более не 180 кил. Любая
> прокачка/обработка гигов не будет слишком быстра.
> Если индексы создаются достаточно долго, значит они
> большие. Не дай бог это какое-нибудь ключевое поле. На
> каждую запись будет происходить поиск уже существующего
> индекса, плюс создание нового. Не имеет ли смысл отказаться
> от индексации?
Отказ от индексов позволяет делать туже работу раз в 10 бысрее (я проверил). Оставлю один, что нужен мне, и может ещё попросят один.
|
|
<software>
|
Как увеличить скорость 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
|
В .NET v 2.0, как оказалось, появилась новая фича SQLBalkCopy - класс обёртка для DTS API.
Тестируется великолепно. В продакшн не пробовал.
|
| |
Дак если не ошибаюсь, эта "фича" была еще в SQL 6.0 (или... 27.11.06 00:04
Автор: leo <Леонид Юрьев> Статус: 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
|
|
|
| | | |
Если талица не создается заново каждый раз, а лишь... 27.11.06 10:36
Автор: Den <Denis> Статус: The Elderman
|
|
Если талица не создается заново каждый раз, а лишь дополняется данными, можно попробовать уменьшить заполнение страниц. Это поможет снизить расходы на выделение страниц БД, но также может существенно повлиять на увеличение размеров БД в сторону увеличения.
|
| | | | |
Пару дней назад мы разбили таблицу на не несколько. Рабочая... 28.11.06 04:50
Автор: void <Grebnev Valery> Статус: Elderman
|
> Если талица не создается заново каждый раз, а лишь
> дополняется данными, можно попробовать уменьшить заполнение
> страниц. Это поможет снизить расходы на выделение страниц
> БД, но также может существенно повлиять на увеличение
> размеров БД в сторону увеличения.
Пару дней назад мы разбили таблицу на не несколько. Рабочая - небольшая там данные только за пару месяцев. Но и то - размер MDF ~ 180 Gbt. Из них преаллокировано и заполнена половина.
|
| | | | | |
Значит у вас эти таблицы создаются каждый раз заново? [upd] 28.11.06 12:27
Автор: Den <Denis> Статус: 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
|
|
Можно эту одну большую таблицу разбить на несколько. Ключевое слово partitioning.
|
|
Можно попробовать дропнуть индексы до вставки и пересоздать после. 23.11.06 07:55
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
|
|
| |
Попробовал на тестовой таблице в 180 Gbt. Один индекс... 28.11.06 04:57
Автор: void <Grebnev Valery> Статус: Elderman
|
|
Попробовал на тестовой таблице в 180 Gbt. Один индекс создаётся в течение 1 часа. Всего 10 индексов, хотя без части из них можно, думаю, обойтись.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
