2014-04-18 2 views
0

Я хочу понять лучший подход для архитектуры SQL Server в рабочей среде.Архитектура SQL Server в производственной среде

Вот моя проблема:

У меня есть база данных, которая имеет в среднем около 20 000 записей вставляются каждый второй в различных таблицах.

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

Мы реализовали

  • Таблица Partitioning
  • Индексация
  • И все другие необходимые вещи.

Мой вопрос: может ли кто-нибудь предложить архитектуру, которая имеет разные базы данных SQL Server для отчетов и приложений, и они могут синхронизировать себя в сети каждый раз, когда новые данные вводятся в главный SQL Server?

Некоторые из них, как Мастер и рабская архитектура. Я понимаю архитектуру Master и Slave, но мне нужно больше обдумать ее.

Наши основные таблицы, имеющие около 40 миллионов строк (таблица разделение сделано)

+0

Другая база данных не позволит вам сэкономить. Вы исчерпываете ресурсы, которые имеет сервер. Любой диск или процессор. Это может быть проблемой блокировки. Вы должны диагностировать его и исправить, а не переходить на ядерную со второй базой данных. Посмотрите на изоляцию моментальных снимков. – usr

+0

У меня много процессора и оперативной памяти, то есть 64-ядерный процессор и 132 ГБ оперативной памяти, я могу рискнуть, чтобы он был исчерпан до некоторой степени. Определите узкие места, взаимоблокировки и т. Д., И зафиксировали это с командой. Я хотел бы обратить внимание на руководство с лучшей архитектурой. –

+0

Я не получил этого заявления. Проблема уже решена? Действительно, вы, вероятно, не исчерпываете процессор, но вы можете исчерпать диски. Отдельная база данных почти всегда не является правильным решением, поскольку она вызывает больше проблем, чем необходимо. – usr

ответ

1

В SQL Server 2008R2 у вас есть зеркальное отображение базы данных и репликации доступны, который будет держать две базы данных в синхронизации.

Схема, эффективная для OLTP, вряд ли будет эффективной для отчетов большого объема. Базы данных «вживую» и «отчетность» должны иметь разную схему с процессом ETL, перемещающим данные от одного к другому. Я бы хотел обсудить с бизнесом, насколько синхронизирована база данных отчетов. Если отчеты обрабатывают большие объемы данных, им потребуется некоторое время для запуска, поэтому отставание в репликации данных не будет замечено, я бы предложил. В экстремальном режиме вы можете построить решение с помощью Service Broker для перемещения данных и обработки на сервере отчетов, чтобы распространять его на таблицы отчетов.

Цифры, которые вы цитируете (20 000 вставок в секунду, 40 миллионов строк в наибольшей таблице), указывают на то, что запись не долгое время находится в БД. У вас будет значительная загрузка, выполняющая DELETE с. Оптимизация этих часов пик может быть достаточной для решения ваших проблем.

+0

Спасибо, Майкл, будет больше исследовать Service Broker. Данные в таблицах всегда есть, поэтому мы сделали Табличную оценку, разбиение было сделано в течение финансового года. Я также хочу отметить, что в базе данных Live и отчетов используется другая схема. –