Визначення проблеми

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

Навантаження

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

Сучасне рішення та проблема

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

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

Розглянуті підходи

Кластеризація

У нас було включено кластеризацію баз даних, але це не відповідало потребам надання даних доступними та просто загалом ускладнило життя адміністратора. З тих пір вимкнено.

Реплікація SQL Server

Ми почали розглядати реплікацію минулого тижня. Наша теорія полягає в тому, що ми можемо отримати другий каталог, який склався і синхронізувався з виробничою базою даних. До початку ETL ми припинимо з'єднання і повторно ввімкнемо його лише після завершення процесу ETL.

Адміністратор почав з реплікації знімка, але він стурбований тим, що для отримання знімка потрібні кілька днів високого використання процесора, а також необхідне споживання диска. Він вказує, що видається, що всі дані надсилаються у фізичні файли перед тим, як коли-небудь відправити передплатнику, тому наша база даних .6TB обійдеться у 1,8 ТБ у витратах на зберігання. Крім того, якщо для отримання оснащення знадобиться кілька днів, то він не впишеться в потрібний угода про угод.

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

Дзеркальне відображення бази даних

Наша база даних перебуває у ПОВНОМУ режимі відновлення, тому дзеркальне відображення бази даних є варіантом, але я знаю про неї навіть менше, ніж Реплікація. Я знайшов відповідь ТА, яка вказувала: "Дзеркальне відображення баз даних перешкоджає доступу до даних безпосередньо, до дзеркальних даних доступний лише знімок бази даних".

Доставка журналу

Здається, що доставка журналів також може бути варіантом, але це ще одна з тих речей, про які я нічого не знаю. Це було б рішення з меншими витратами (впровадження та обслуговування), ніж будь-що інше? На підставі коментаря Ремуса "Доставка журналів дозволяє отримати доступ лише для читання до копії репліки, але відключить всіх користувачів при застосуванні наступного отриманого журналу резервного копіювання (наприклад, кожні 15-30 хвилин)." Я не впевнений, як довго цей час простою перетвориться на те, що може викликати у користувачів деякий стурбованість.

MS Sync

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

SSIS

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

"Чарівний" знімок SAN

Раніше я чула, як наш адміністратор використовував деяку технологію SAN для того, щоб робити миттєві резервні копії цілих дисків. Можливо, є якась магія ЕМС, яка може бути використана для виготовлення копій mdf / ldf уберквік, і ми можемо потім від'єднати / приєднати цільову базу даних.

Резервне копіювання і відновлення

Я думаю, що ми робимо повні резервні копії раз на тиждень, різняки щоночі та тривалість кожні 15 хвилин. Якщо користувачі могли б жити з відключенням на 3-4 години для повного відновлення, я думаю, це може бути підходом.

Обмеження

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, EMC SAN-накопичувач із накопичувачами, відображеними на файли vmdk, резервне копіювання файлів обмінні файлами та .6TB даних у вихідному каталозі. Це стороннє додаток, яке ми розміщуємо вдома. Зміна їх структури, як правило, нахмуриться. Користувачі не можуть пройти без запитів у базі даних та відмовитись від обмеження, попередньо ідентифікуючи таблиці, які вони контролюють, щоб виконати свою роботу.

Наші DBA на даний момент є суто підрядниками. Штатники відпливли, і ми ще їх не замінили. Адміністратори програми недостатньо розбираються в питаннях SQL Server, і у нас є команда адміністраторів Storage / VM, яка могла б допомогти / перешкодити цьому. Наразі команди розвитку не беруть участь, але можуть бути зараховані на основі підходу. Таким чином, більш простим у виконанні та підтримці рішення було б краще.

Я, я сторонник розвитку, тому я можу лише пропонувати підходи, і мені не довелося мати справу з адміністративною стороною. Тому, не маючи часу на адміністративному сідлі, я не вагаюся сказати, що один підхід був би кращим за інший — це все виглядає чудово згідно з документами. Я повністю готовий керувати будь-яким напрямком, який ви пропонуєте, тому що, як я бачу, це зробить мене ще більш цінним як професіонала БД. У мене тачка, але плащ з холокостом не доступний .

Пов'язані питання

• /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• /programming/434982/mirroring-vs-replication

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Правки

Щоб вирішити питання @ onpnt

Прийняття затримки даних

Наразі користувачі переглядають дані, які відстають на 24 години. Дані поточні лише на 2200 рік

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

Підключення до вторинного

Внутрішня мережа, окремий віртуальний хост і виділене сховище

Прочитайте вимоги на другорядній інстанції

Група Windows матиме доступ до читання до другорядних, усіх таблиць

Час роботи вторинної інстанції

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

Зміни до існуючої схеми та всіх об'єктів

Нечасті модифікації, можливо, один раз на квартал для об’єктів таблиці. Можливо, один раз на місяць для об'єктів коду.

Безпека

Ніяких особливих потреб у безпеці. Дозволи на виробництво відповідатимуть дозволам на копію. Хоча, як я думаю про це, ми могли б позбавити користувачів читати доступ до prod і лише дозволити їм читати копію ... Хоча це не обов'язково.

@darin протока

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

@cfradenburg

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

Загорнути

2012-10-29 Ми оцінили магію знімків ЕМС та деякі інші варіанти реплікації, але DBA вирішили, що вони можуть найкраще з'ясувати Mirroring. Відповіді схвалили, бо всі вони допомогли і дали мені безліч варіантів, а також "домашніх завдань" для дослідження.

Зміна їх структури, як правило, нахмуриться

Реплікація більш ніж ймовірна, і я б викинув синхронізацію перед цим. (з реальних життєвих високих трансакітональних тестів на Sync Framework)

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

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

SSIS не призначений просто скидати дані, але він може це зробити. Ви занадто сильно дивитесь на перетворення пошукових запитів, хоча завдання буде дорого за часом та ресурсами. Хоча, як я вже сказав, це може зробити.

Дійсно, буде чітке звуження вибору, засноване на відповіді на кілька запитань

• Прийняття затримки даних
• Кількість змін даних за певну хвилину, годину та день Підключення до другорядного
• Прочитайте вимоги на другорядній інстанції
• Час роботи вторинної інстанції
• Зміни до існуючої схеми та всіх об'єктів
• Безпека

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

Щоб розширити функцію доставки журналу, не потрібно відновлювати журнали кожні 15-30 хвилин. Якщо ви вирішите, ви можете робити це кожні чотири години або раз на день. Рішення, подібне до цього, яке я реалізував - це робити щотижневе повне резервне копіювання та відновлення до БД звітування (що може зайняти деякий час і трапитися у вихідні дні). Протягом тижня проводяться диференційні резервні копії, і щорічно їх повертає до бази звітів. Користувачі повинні отримати завантаження перед відновленням, але оскільки звітний БД є додатком робочого часу, з цим не виникає проблем. Дані - це день, який не повинен бути проблемою з урахуванням ваших вимог.

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

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

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

1. Вам не доведеться ініціалізувати абонента знімком. Ви можете взяти резервну копію видавця та ініціалізувати її.
2. Ви можете призупинити доставку команд для абонента, просто зупинивши завдання розповсюдження (це просто звичайне завдання SQL Agent або у дистриб'ютора, або в підписника, залежно від того, встановили ви його відповідно як підписка на push або тягнення). Пам’ятайте лише про своє утримання у дистриб'ютора, щоб зберегти достатню кількість історії, яку ви зможете наздогнати.
3. Ви можете змінити індексацію у абонента, щоб розмістити навантаження, яке буде виконуватися там (імовірно, тип звітування), замість того, щоб приймати індексацію від свого видавця (імовірно, типу OLTP), якщо ви цього хочете.