Розділення таблиць для архівування даних

13

Сценарій:

дві бази даних: DB_A і DB_Archive з однією дуже великою таблицею під назвою tableA.
щодня записи, старші за 60 днів, видаляються з DB_A та переміщуються до DB_Archive, головним чином, щоб залишити річ "розділеною", оскільки таблицяA запитується в DB_A для записів останніх 2 місяців.

Я хочу позбутися цього процесу, тому що він повільний і витрачає багато ресурсів. Я думаю про реалізацію розділення таблиці на DB_A з функцією розділу в стовпці дати та зберігання всіх записів <2 місяці на одному розділі та всіх записів> 2 місяці на іншому розділі. Мої запитання:

чи поводитиметься цей сценарій так, якби у мене були 2 різні бази даних? Якщо я запитую свою таблицюA щодо записів> getdate () - 30, чи буде вона читати розділ архівування?
Я вважав, що я повинен також розділити індекси, правда?
Як я маю справу з тим, що завтра моя функція розділення "зміниться", я маю на увазі, якщо я буду створювати функцію сьогодні (2 липня, її діапазон буде 2 травня, а завтра - 3 травня). Чи можу я створити функцію динамічного розділу?

sql-server sql-server-2005 partitioning

— Дієго
джерело

Я не думаю, що динамічна функція є гарною ідеєю, навіть якщо вона була дозволена (я не думаю, що це є) ... ми можемо детальніше розібратися найближчим часом, але я думаю, ви, мабуть, повинні розділити на основі дати календаря та рухатися. одна секція за часом ... Але тут є різноманітні варіанти.

— JNK

Я склав сценарій прикладу того, що ви хочете зробити минулого року. Це був дещо особливий випадок, коли ми хотіли зберігати x днів даних у швидкому (дорогому) масиві та переміщувати архівні дані до дешевшого зберігання. Якщо я можу переосмислити приклад сценарію, я опублікую його, інакше це буде просто зведення процесу.

— Марк Сторі-Сміт

привіт, познач, так, будь ласка, і якщо ти можеш поділитися своїм досвідом. це було успішно?

— Дієго

Це працює, але в кінцевому рахунку було непотрібним (ми взяли простіший маршрут). Можливо, ви могли б розширити, чому у вашому випадку існує 60-денна межа? Допоможе всім вказати вас у правильному напрямку.

— Марк Сторі-Сміт

6

З розділенням вам доведеться робити розділ на день, що ставить ліміт до 1000 розділів Pre-SQL 2012 у новій перспективі, оскільки це дозволить лише три роки архіву. За допомогою SQL Server 2012 ви отримуєте 15000 розділів, що достатньо для 1 розділу в день.

Щодня ви додавали б новий розділ. Якщо ви хочете перемістити розділ 61-го минулого дня, ви можете зробити це ефективно, але це все ще в режимі офлайн. Див. Розділ Ефективне переміщення розділу до іншої групи файлів .

Усі ваші індекси повинні бути вирівняні, див. Спеціальні вказівки щодо розділених індексів .

Придбати перегородку - це непросте рішення, і це може бути досить великим перекусом для пережовування ... див. Як вирішити, чи слід використовувати розділ таблиці . Зокрема, не слід очікувати на покращення продуктивності від розділення. Ви повинні підходити до проблем продуктивності в найменший час, кластеруючи по даті.

— Ремус Русану
джерело

Новий ліміт доступний у SP2 2008 та R2 SP1 2008 року. blogs.msdn.com/b/hanspo/archive/2010/11/29/…

— Джон Сейгель

@Jon: впровадження SP2, 2008R2 SP1 2008 року з великим попередженням . As explained in this white paper, there are implications on certain features, including performance. . Підтримка SQL 2012 не має попереджень.

— Рем Русану

Дякую, що вказали на це; правда, є деякі застереження щодо його використання на 2008/2008 R2, але це можливо, якщо це необхідно.

— Джон Сейгель

дякую за ваш коментар Я прочитаю коментар до матеріалу пізніше

— Дієго

2

Я не знаю, чи може функція розбиття бути динамічною, але я сумніваюся. Деякі варіанти для вас, не йдучи цим маршрутом:

1 - Розділ у календарі DATE та переміщуйте найстаріший розділ щодня

2 - Створіть подання, яке фільтрує дату, і вкажіть усі існуючі запити там (цим можна легко керуватися, перейменувавши базову таблицю на щось інше і назвавши подання, як називається поточна таблиця). Це можна оптимізувати і при зміні індексу.

Майте на увазі, що перший варіант вище буде працювати ЛОТО краще, якщо ви використовуєте поле дати у своїх запитах. Якщо ви цього не зробите, це все ще буде швидше, ніж поточний процес, але запити не матимуть значних покращень. Розбиття в основному найкраще працює, якщо ви можете фільтрувати поле свого розділу, і оптимізатор знає, на який розділ слід звернути увагу.

— JNK
джерело

Я хотів би уникати ручних операцій "щодня"

— Дієго

2

Ось що має працювати для вас: DB_A - tableA з різним розділом за кожне з останніх 60 днів - stagingTable для переміщення даних із найстарішого розділу

Таблиця DB_ArchiveA - зберігає всі дані старші 60 днів. (не розділено)

Процес: 1. до кінця дня: змінити функцію розділу - розділити діапазон, щоб додати новий розділ для нового дня. (Примітка: замість того, щоб створювати розділи для "сьогоднішньої дати + 1 день", ви можете зробити на кілька кроків попереду. Наприклад: "сьогоднішня дата + 5 днів"

Після закінчення кожного дня ви спочатку перемикаєте найдавніший розділ у DB_A.tableA на DB_A.stagingTable; Об’єднайте найдавніші перегородки.
Імпортуйте дані з DB_A.stagingTable в DB_Archive.tableA. Нарешті trunacte DB_A.stagingTable

Вищезазначене називається Rolling Window і є досить поширеним сценарієм для VLDB. Ознайомтеся з цією білою книгою від Microsoft для розбиття розділів: Таблиця розділів та стратегії індексів або спробуйте це спеціально у сценарії "Розсувне вікно"

— Дхармендар Кумар 'ДК'
джерело

0

Ви можете використовувати динамічний підхід архівації та очищення даних у SQL Server. Для цього перейдіть за посиланням нижче.

http://www.sqlscientist.com/2012/09/auto-maintain-archival-process.html

— Асиф Ганчі
джерело

1

Не могли б ви включити у свою відповідь основні моменти цієї публікації? Знаєте, посилання приходять і йдуть, а коли вони йдуть, у вашій пошті буде лише мертве посилання.

— dezso