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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Значит у вас эти таблицы создаются каждый раз заново? [upd] 28.11.06 12:27  Число просмотров: 2769
Автор: 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-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach