Назад | Перейти на главную страницу

SQL 2008. Помогите выбрать правильную модель репликации

База данных представляет собой хранилище данных на конец дня с некоторыми отчетами.

Мы заполняем базу данных данными для конкретной даты каждый день.

Время от времени пользовательские отчеты блокируют процессы импорта (запускаются из приложений C #, а затем с помощью sprocs, обрабатывающих данные на стороне SQL).

Итак, моя идея состоит в том, чтобы отделить отчеты от хранения в 2 отдельных dbs.

Вы бы согласились?

Если что мне нужна репликация. Какая была бы рекомендация?

Я могу получить еще один ящик в том же дата-центре. Объем данных составляет около 2 ГБ в день.

Я не получу трехмерную коробку, поэтому SSRS должен быть установлен поверх базы данных отчетов.

Потребовалось время, чтобы разобраться в проблеме. Поправьте меня, если я ошибаюсь.

У вас есть база данных, в которую вы загружаете данные только для одних данных, и пользователи запрашивают отчеты по этим данным. Но в процессе импорта (выполняется только один раз в день) отчеты блокируются. Ежедневно добавляется 2 ГБ данных. И вы хотите оптимизировать этот процесс.

Что такое SELECT @@ VERSION? Я знаю, что вы используете 2008, но мне также нужна информация о выпуске. Вы добавляете 2 ГБ данных или усекаете и загружаете только 2 ГБ каждый день? Сколько памяти доступно на коробке? Можете ли вы также поделиться информацией из приведенного ниже запроса.

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS
(SELECT wait_type, wait_time_ms / 1000. AS wait_time_s,
100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct,
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK'
,'SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE'
,'REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT'
,'CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT'
,'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP'))
SELECT W1.wait_type, 
CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2
ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 99 OPTION (RECOMPILE); -- percentage threshold

SQL Server очень мощный, и при правильном использовании может получить от него большую производительность. Сейчас у нас недостаточно информации, чтобы вынести суждение. Вам может понадобиться REPLICATION, или вы можете просто улучшить производительность, настроив производительность, добавив соответствующие индексы и выбросив мало памяти. Пожалуйста, добавьте больше деталей.

Если вы хотите использовать эту базу данных только для отчетов, вам следует подумать об использовании регистрации в режиме только для чтения.