Наразі ми стикаємося з деякими проблемами продуктивності, оскільки наша база даних стає занадто великою. Є дані, що зберігаються за останні 10 років, і я не бачу причини, за якою дані, старші 2 років, повинні зберігатися в тих же таблицях, що і нові дані.

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

Інформація

• Всього в базі даних є близько 310 000 записів.

• Базі даних потрібно 250 Гб на жорсткому диску.

• Версія сервера - це SQL Server 2008 з рівнем сумісності SQL Server 2005 (90), але ми плануємо найближчим часом оновити до SQL Server 2012

Я думав про дві можливості:

Нова база даних

Створіть Базу даних, подібну до тієї, на виробничому сервері та вставте всі старі дані в нову базу даних.

• Недолік: Оскільки пов'язані сервери заборонені в нашому середовищі, було б важко приєднатися до старих даних, якщо потрібно

Схема історії

Створіть нову схему fe [hist] з тими ж таблицями, що і у виробничій базі даних. Вставте всі старі дані в ці нові таблиці в новій схемі.

• Перевага: Легке приєднання, якщо в майбутньому потрібні старі дані

• Ви віддаєте перевагу одному з рішень над іншим?
  • Чому?
• Чи є кращі можливості?
• Чи існують інструменти, за допомогою яких це завдання легко можливо?
• Будь-які інші думки?

Спасибі заздалегідь

Редагувати

Додаткове запитання:

Чи потребує новостворена таблиця архівів первинний / зовнішній ключі?

Або вони повинні просто мати стовпці, але без ключів / обмежень?

Я думаю, що відповідь на багато ваших питань полягає в тому, що це залежить. Які проблеми у роботі є? Мабуть, незвично, що база даних матиме проблеми з продуктивністю лише від зростання до 250 ГБ.

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

Ви віддаєте перевагу одне з рішень над іншим?

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

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

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

Чи є кращі можливості?

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

Чи потребує новостворена таблиця архівів первинний / зовнішній ключі? Або вони повинні просто мати стовпці, але без ключів / обмежень?

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

Будь-які інші думки?

Оскільки ви використовуєте Enterprise Edition і плануєте оновити до SQL 2008+, ви можете розглянути можливість стиснення даних для цієї таблиці. Стиснення, безумовно, зменшить дисковий простір, але залежно від диска та ресурсів процесора, воно також може покращити ефективність запитів для читання за рахунок зменшення вводу / виводу диска та покращення використання пам’яті (більше даних вміщується в кеші відразу).

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

Але оскільки у вас є корпоративне видання, у вас є третій варіант - розділити свої таблиці, що при їх створенні полегшує архівування даних і запит на старі дані, прозорі для користувачів, і вам не потрібно буде вносити зміни в додаток .

На мій досвід, друга база даних була б кращим вибором з двох причин.

1. Ви можете відновити дані з історичної резервної копії, потім скинути таблиці та індекси, які вам не потрібні.
2. Ви можете перемістити це на інший сервер для цілей звітності, це має переваги від використання ресурсів основного сервера

Вам все одно потрібно буде видалити всі історичні дані з первинної бази даних, але це може бути заплановано в.

На даний момент ігнорування ліцензії, оскільки я не витрачаю свій час.

ІМХО, архів бази даних є найпростішими для реалізації і підтримки. Вони є чіткими, нещільно пов'язаними сутностями. Контроль руху та завантаження даних / ресурсів має чіткі межі. Легше перейти на інший примірник чи сервер для кращого управління продуктивністю та витратами - це не головна проблема. Зауважте, що найпростіше! = Найдешевше або найменше зусиль. Насправді є дещо більше завдань, але все це прості завдання з двома важливими винятками:

1. виконання обмежень - не існує такого поняття, як обмеження міжбазової бази даних у SQL Server, тому вам потрібно вирішити, чи є це вимикачем угод.
2. крос-запити баз даних використовують розподілені запити, які все ще залежать від застарілого OLEDB. Це означає, що ви можете зіткнутися з проблемами з новими типами даних плюс, якщо у вас виникнуть проблеми з ефективністю, навряд чи вони коли-небудь виправляться

Архівна схема або просто таблиця архіву є трохи складнішою для реалізації, але набагато простішою у використанні. Усі об’єкти в одній базі даних означають, що вам не доведеться копіювати та підтримувати елементи контролю доступу. Немає крос-запитів до бази даних, що спрощує налаштування продуктивності, моніторинг, усунення несправностей тощо ...

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

Деякі важливі міркування:

• Чи регулярно повертаються запити історичних / холодних даних або нечасто доступні холодні дані?
• Чи історичні дані незмінні чи вони регулярно оновлюються / видаляються?
• 310м рядків "помірний" (якщо вважати всі в 1 таблиці) залежно від розміру рядків. Чи є у вас дані про розмір рядків? Скільки ГБ - це 310 м ряд?
• Який темп зростання цієї таблиці?
• Чи можете ви змінити код програми та його SQL запити?

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

Крім того, якщо ви думаєте про оновлення, врахуйте 2016 рік та нову функцію бази даних Stretch: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Я вважаю за краще розділити базу даних на окрему логічну базу даних з наступних причин:

1. Вимоги до ресурсу

Розбивши це на окрему базу даних, її можна зберігати на іншому диску та контролювати з різною швидкістю до основних виробничих даних.

2. Продуктивність

Розбиваючи дані на окрему базу даних, основна виробнича база зменшується в розмірах, що сприяє загальній продуктивності.

3. Простіші резервні копії

Резервне копіювання заархівованих даних не може вважатися таким важливим, як "живі / поточні" записи в основній базі даних SQL. Це може означати, що архівні дані можуть бути резервні копії рідше. Зважаючи на послідовний характер реєстрації архівованих даних, можливо зробити резервне копіювання розділів архівованої бази даних один раз, а потім ніколи більше. Наприклад, коли дані архіву будуть записані в базу даних Змінити архів за 2014 рік, вони більше ніколи не зміняться.

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