Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Оцените предполагаемое секционирование таблицы  [new]
alister
Member

Откуда:
Сообщений: 91
Собираюсь реализовать секционирование таблицы на MS SQL 2008 R2, в таблице больше 1 млрд записей, размер данных таблицы 85ГБ.
В день добавляется до миллиона записей.
На таблице кластерный индекс, который включает DayDate - целое представление даты, по нему и будет секционирование.
Предполагается оптимизация в части скорости при добавлении записей в таблицу и при выполнении мейнтененса.
create partition function pf_xdaily ( int )
as range right for values ( 40177, 40542, 40907);
go

create partition scheme ps_xdaily
as partition pf_xdaily
to ( [PRIMARY],[FG2010],[FG2011],[FG2012]);
go

CREATE TABLE [Daily](
[AmountId] [dbo].[TRowId] NOT NULL,
[DayDate] [dbo].[TDate] NOT NULL,
[CrncyDebit] [dbo].[TMoney] NOT NULL,
[CrncyCredit] [dbo].[TMoney] NOT NULL,
[CrncyAmount] [dbo].[TMoney] NOT NULL,
[MainDebit] [dbo].[TMoney] NULL,
[MainCredit] [dbo].[TMoney] NULL,
[MainAmount] [dbo].[TMoney] NULL,
CONSTRAINT [IDailyIdentity] UNIQUE CLUSTERED
(
[DayDate] ASC,
[AmountId] ASC
) ) ON [ps_xdaily]([DayDate])

Оставшийся индекс NONCLUSTERED INDEX [IDailyAmountId] по полю AmountId будет вынесен в отдельную файловую группу.
Таблицу Daily предполагается выгрузить через bcp и потом загрузить в созданную секционированную таблицу Daily.
Правда, при реализации этой схемы на тестовом сервере столкнулся с проблемой нехватки места под tempdb, которой 75 ГБ свободного места не хватило.
28 фев 12, 11:07    [12162124]     Ответить | Цитировать Сообщить модератору
 Re: Оцените предполагаемое секционирование таблицы  [new]
edyaN
Member

Откуда: Berlin
Сообщений: 185
alister,

ну я бы выгружал частями и сразу в правильную группу, тогда и tempdb не так сильно росла бы.
create table daily2010 (....) on fg2010
create table daily2011 (....) on fg2011
go
insert into daily2010 select * from daily where daydate < 40177
insert into daily2011 select * from daily where daydate >= 40177 and daydate < 40542

и так далее.
Потом построите ограничения для daydate, кластерный индекс и переключите секции.

а зачем в кластерном индексе AmountID?
подумайте, действительно ли он там нужен?
28 фев 12, 12:50    [12162966]     Ответить | Цитировать Сообщить модератору
 Re: Оцените предполагаемое секционирование таблицы  [new]
alister
Member

Откуда:
Сообщений: 91
Наверное, все таки будет так
create table daily2009 (....) on Primary
create table daily2010 (....) on fg2010
create table daily2011 (....) on fg2011
go
insert into daily2009 select * from daily where daydate < 40177
insert into daily2010 select * from daily where daydate >= 40177 and daydate < 40542
...

>>Потом построите ограничения для daydate
не совсем понятно, что имеется в виду
>>а зачем в кластерном индексе AmountID?
Структура таблицы не наша, для выполняемых запросов кластерный индекс именно в таком виде оптимален
28 фев 12, 18:19    [12165922]     Ответить | Цитировать Сообщить модератору
 Re: Оцените предполагаемое секционирование таблицы  [new]
edyaN
Member

Откуда: Berlin
Сообщений: 185
alister
Наверное, все таки будет так
create table daily2009 (....) on Primary
create table daily2010 (....) on fg2010
create table daily2011 (....) on fg2011
go
insert into daily2009 select * from daily where daydate < 40177
insert into daily2010 select * from daily where daydate >= 40177 and daydate < 40542
...


ну я бы не хранил ничего в primary, и если есть данные за 2009 , то создал бы для нее файловую группу.
alister
>>Потом построите ограничения для daydate
не совсем понятно, что имеется в виду

как-то так:
alter table daily2010
add constraint constraint CK_daily2010_day check (daydate < 40177)

это нужно для того, чтобы переключить секции.
29 фев 12, 13:32    [12169743]     Ответить | Цитировать Сообщить модератору
 Re: Оцените предполагаемое секционирование таблицы  [new]
alister
Member

Откуда:
Сообщений: 91
edyaN
ну я бы не хранил ничего в primary, и если есть данные за 2009 , то создал бы для нее файловую группу.

Чем в данном случае плох primary, если в нем уже хранится вся база?
Например, здесь предложено использовать primary, как первую секцию: 11881174
А вообще есть данные не только за 2009 год, но за все года, начиная с 1999.
вот только я не вижу большого смысла выделять отдельные файловые группы годам ранее 2010. Возможности все их разложить по отдельным дисковым массивам нет.
Сейчас распределение по количеству записей такое:
до 2010-го
кол-во записей 632250329
2010-й
кол-во записей 198421721
2011-й
кол-во записей 218219463
2012-й
кол-во записей 34317125
29 фев 12, 21:20    [12173354]     Ответить | Цитировать Сообщить модератору
 Re: Оцените предполагаемое секционирование таблицы  [new]
edyaN
Member

Откуда: Berlin
Сообщений: 185
alister
Чем в данном случае плох primary, если в нем уже хранится вся база?

Бекапить долго. можно создать на каждый год свою группу, перенести туда данные, пометить ее read only и забекапить.
И в дальнейшем можно бекапить только primary. Меньше данных-> быстрее backup -> меньше нагрузка -> меньше потребления электричества -> ваш вклад в борьбу с глобальным потеплением. :)

Но если этот вопрос Вас не напрягает, то можно все оставить как есть.
alister
Например, здесь предложено использовать primary, как первую секцию: 11881174

Я так понял, что там как раз в primary ничего не храниться. Но это были только догадки.
Если Вы еще это еще не читали, то очень рекомендуется:
https://www.sql.ru/articles/mssql/2005/073102partitionedtablesandindexes.shtml
1 мар 12, 15:54    [12177794]     Ответить | Цитировать Сообщить модератору
 Re: Оцените предполагаемое секционирование таблицы  [new]
alister
Member

Откуда:
Сообщений: 91
edyaN
Но если этот вопрос Вас не напрягает, то можно все оставить как есть.

Спасибо за комментарии, реализовал схему на рабочей системе, от использования Primary для секционированной таблицы полностью отказался
В результате наблюдается существенное ускорение перестройки индексов и скорости вставки в секционированную таблицу.
5 мар 12, 11:13    [12194084]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить