информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Страшный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft сообщила о 44 миллионах... 
 Множественные уязвимости в VNC 
 Шестой Perl превратится в Raku,... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / software
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Значит у вас эти таблицы создаются каждый раз заново? [upd] 28.11.06 12:27  Число просмотров: 2428
Автор: Den <Denis> Статус: The Elderman
Отредактировано 28.11.06 12:31  Количество правок: 1
<"чистая" ссылка>
Если в существующую таблицу БД интенсивно вставляются строки - имеет смысл уменьшить процент заполнения страниц для увеличения скорости добавления записей.
Если же каждый раз таблицы создаются заново - имеет смысл увеличить процент заполнения страниц для более плотного размещения записей, что может существенно уменьшить размер БД и даже увеличить скорость чтения данных из таблиц.
<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 индексов, хотя без части из них можно, думаю, обойтись.
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach