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

Откуда: Москва
Сообщений: 109
День добрый всем.
Подскажите как лучше решить задачу. Есть приложение, есть БД. Приложение - по большому счету самописное, БД - SQL2008. Нагрузка на базу неравномерная и разная. Постоянно идет массовая вставка, плюс днем разнообразные отчеты создают большую нагрузку. Идея такая, что отчетную нагрузку вынести в отдельную БД и другой сервер. На уровне приложения реализовать это немного затруднительно. На уровне SQL - хотелось бы выбрать наилучший способ копирования данных.
Первое, что придумалось - репликация. Но снапшотами не очень подходит, размер БД более 600Гб (нагрузка на сеть, да и места где столько взять, для снапшотов), а транзакционная модель выявила проблему, что на многих таблицах нет первичных ключей. А без примари кей транзакционная репликация работать не будет...
bcp? Но как-то фильтровать данные по сотне таблиц, дабы копировать только новые. Задача тоже непростая.
Что еще?
29 янв 16, 14:27    [18745618]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8301
JohnAl,

доставка журнала транзакций, например. Log shipping.
29 янв 16, 14:32    [18745650]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
Glory
Member

Откуда:
Сообщений: 104760
https://msdn.microsoft.com/en-us/library/ff877884.aspx
29 янв 16, 14:34    [18745667]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
JohnAl
Member

Откуда: Москва
Сообщений: 109
Лог шиппинг держит копию БД в состоянии NoRecovery. Какие уж тут отчеты собирать.
Алвайс он - это да, подходит. Но потребуется модернизация минимум двух SQL серверов до 2012 или сразу уж до 2014. Причем, емнип, нужна версия энтерпрайз? Так то весь продуктив на стандарт 2008 вполне успешно работает не первый год.
29 янв 16, 14:44    [18745744]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
o-o
Guest
JohnAl
Лог шиппинг держит копию БД в состоянии NoRecovery. Какие уж тут отчеты собирать.

или StandBy (ReadOnly)
все прекрасно читается
29 янв 16, 14:46    [18745747]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
o-o
Guest
JohnAl
Алвайс он - это да, подходит. Причем, емнип, нужна версия энтерпрайз?

ага. и вин сервер такой же.
оно кластер требует
29 янв 16, 14:47    [18745757]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
Glory
Member

Откуда:
Сообщений: 104760
JohnAl
Лог шиппинг держит копию БД в состоянии NoRecovery

А также STANDBY

JohnAl
Какие уж тут отчеты собирать

Вопрос скорее будет, а как отключить собиральщиков отчета для возможности восстановления следующего бэкапа журанала

JohnAl
Но потребуется модернизация минимум двух SQL серверов до 2012 или сразу уж до 2014. Причем, емнип, нужна версия энтерпрайз?

Прокалькулируйте затраты на создание рукописной репликации и сравните
29 янв 16, 14:47    [18745760]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4917
Блог
GoldenGate 12.2 сможет на MSSQL Standard поднять такую репликацию. Плюс в отличие от AlwaysOn он может работать с другой структурой данных (партиционирование, исторические таблицы, дополнительные индексы). Но он стоит денег.
29 янв 16, 15:02    [18745883]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
komrad
Member

Откуда:
Сообщений: 5491
Alexander Ryndin
GoldenGate 12.2 сможет на MSSQL Standard поднять такую репликацию. Плюс в отличие от AlwaysOn он может работать с другой структурой данных (партиционирование, исторические таблицы, дополнительные индексы). Но он стоит денег.

Ну если уж на то пошло, то и Sybase Replication Server может это сделать, причем между разными СУБД.
Тоже стоит денег...
29 янв 16, 15:35    [18746161]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
xenix
Guest
В порядке бреда:
1. самопальный CDC на триггерах на нужные таблицы для формирования дельта-таблиц
2. SSIS-пакет, который возит эти самые дельта-таблицы куда надо
29 янв 16, 16:30    [18746623]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
churupaha
Member

Откуда: Краснодар
Сообщений: 1015
JohnAl
...


в копилку.

mirroring + job +
create database ... as snapshot of MyMirroredDb
29 янв 16, 16:56    [18746891]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
Addx
Member

Откуда:
Сообщений: 957
JohnAl
..., а транзакционная модель выявила проблему, что на многих таблицах нет первичных ключей. А без примари кей транзакционная репликация работать не будет...


Сделайте первичные ключи, в чем проблема? Полезная вещь.
29 янв 16, 18:00    [18747258]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
komrad
Member

Откуда:
Сообщений: 5491
churupaha
JohnAl
...


в копилку.

mirroring + job +
create database ... as snapshot of MyMirroredDb

снэпшоты в Enterprise, а у товарища Standard
29 янв 16, 18:19    [18747365]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
Alexander Us
Member

Откуда:
Сообщений: 1153
JohnAl,

а какую нагрузку Вы имеете ввиду: пиковую или постоянную?

Если пиковая, и она вызвана отчётами:
(что при генерации отчётов резко возрастает нагрузка на сервер, и тормозяься рабочие процессы)

То можно поробовать запросы в отчётах делать с опцией optopn(maxdop 1)
и, если логика отчётов допусуает грязное чтение, то with(nolock)

решение не кошерное, но работает.
29 янв 16, 18:20    [18747377]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
komrad
Member

Откуда:
Сообщений: 5491
JohnAl
bcp? Но как-то фильтровать данные по сотне таблиц, дабы копировать только новые. Задача тоже непростая.

можно нарисовать вьюхи с условием "новизны" и выгружать данные из них
29 янв 16, 18:39    [18747480]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2423
JohnAl,

А этап оптимизации запросов уже прошли? а то может просто пройтись по списку самых жирных и этого хватит для снятия нагрузки.
29 янв 16, 18:43    [18747504]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31778
JohnAl
транзакционная модель выявила проблему, что на многих таблицах нет первичных ключей. А без примари кей транзакционная репликация работать не будет...
А ПК не вариант сделать?
30 янв 16, 00:30    [18748774]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
JohnAl
Member

Откуда: Москва
Сообщений: 109
Обновлю старую тему.
Реализовал схему с лог шиппингом, БД в StandBy. Обновление данных шло ночью, а днем - работа пользователей с отчетами. Т.к. сиюминутных онлайн данных им не надо было (отчеты с периодом месяц-год), все всех устраивало. Однако жить с такой схемой не совсем удобно. Например, проблемы с единой системой резервного копирования. Логи то пишутся на диск локально. А остальные бэкапы, на кассеты - через NetBackup. Ну и когда у тебя СРК энтерпрайз уровня, привыкаешь к хорошему. Надо копию - в клиенте все бэкапы видны. Перенос с диска на ленту в автомате, скорость работы, дедуп и т.д. А тут следи отдельно, чтобы логи писались, место на диске и вот это вот все.
Но за это время получилось купить лицензию на SQL энтерпрайз 2016, жаль, что только один ) Ну все думаю, теперь заживем ) Колоночные индексы - это вещь. Однако, разрешить проблему с нагрузкой, которая препятствует вставке данных, даже они не помогли. Но тут такое, 450 удаленных БД единовременно скидывают данные в одну общую... БД главная более 1тб уже. В целом - все справляется, однако от лог шиппинга избавится получилось только на три месяца (в это время потребители отчетов как раз не работали), сейчас вот опять возвращаю прежнюю схему. Формально, по счетчикам, все работает без напрягов. Блокировок практически нет. В реальности же, есть еще уровень приложения. И вот на нем - затык. Как только отчеты начинают тянуть данные - дело швах, производительность падает
23 янв 17, 17:38    [20136554]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
Радикально решить проблему отчетов помогут только заранее подготовленные для репортинга данные, кубы, BI и т.д.
23 янв 17, 17:53    [20136665]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8301
JohnAl,

а что, отчеты у вас гигабит сети на лопатки кладут? Разбирались - в чем дело-то?
23 янв 17, 18:05    [20136719]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2423
Владислав Колосов
JohnAl,

а что, отчеты у вас гигабит сети на лопатки кладут? Разбирались - в чем дело-то?


я ТС про это еще год назад спрашивал, тишина.
24 янв 17, 12:27    [20139088]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
JohnAl
Member

Откуда: Москва
Сообщений: 109
Да дело не в сети...
Там проблем много и разных. И отсутствие некоторых полей в таблицах (чтобы уменьшить джойны) и массовая вставка в несколько таблиц. И постоянная не массовая вставка в множество других. Чтение тоже и постоянное и если конец месяца - массовое. Я уж и по файловым группам, дискам / рэйдам и т.д. все разнес. Ребилд индексов, обновление статистик - все есть. На отчетах ISOLATION LEVEL READ UNCOMMITTED, где только можно... Но от структуры, которое задает приложение, все равно не уйдешь. Если у тебя, скажем, активно используемая таблица на 700млн записей (из них ежедневно меняется около 10-20млн), объемом под 500гб, то что тут сделаешь. Писали разработчики приложение под 10 магазинов, а их сейчас 450 уже...

ЗЫ: из забавного. Log shipping на Windows2012R2 (для всех версий SQL от 2008 до 2016) отказался работать до установки NetFramework 3.5. SqlLogShip.exe требует именно его, 4 - не устраивает. А т.к. в 2012 net3.5 по умолчанию не ставится, испытал массу интересных минут )
25 янв 17, 15:39    [20145154]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17196
автор
Если у тебя, скажем, активно используемая таблица на 700млн записей (из них ежедневно меняется около 10-20млн), объемом под 500гб, то что тут сделаешь.


секционирование. вьюха.
25 янв 17, 16:02    [20145354]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
JohnAl
Member

Откуда: Москва
Сообщений: 109
ScareCrow, вьюхи есть
До секционирования пока не дошли, в планах. Варианты выбирают архитекторы.
26 янв 17, 15:08    [20149593]     Ответить | Цитировать Сообщить модератору
 Re: Выбор метода снижения нагрузки на БД (репликация?)  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17196
ну. а за вьюхой у тя может быть что угодно, хоть другой сервер.
26 янв 17, 18:56    [20150855]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить