Источники информации об администрировании больших баз данных SQL Server? - PullRequest
0 голосов
/ 29 июня 2009

В рамках своей роли в фирме, в которой я работаю, меня заставили стать администратором базы данных для нашей базы данных. Некоторые из наших таблиц имеют количество строк, приближающееся к 100 миллионам, и многие из тех вещей, которые я знаю, как сделать SQL Server (например, объединения), просто ломаются на этом уровне данных. У меня осталось пара вариантов

1) Выйдите и найдите администратора базы данных с опытом администрирования VLDB. Это обойдется нам в копеечку и будет стоить другой работы, которую нам нужно выполнить. Я не большой поклонник этого.

2) Большинство наших данных являются историческими данными, которые мы используем для анализа. Я мог бы просто создать копию нашей схемы базы данных и начать с нуля, когда данные откладывают любой анализ наших текущих данных, пока не найду подходящий способ решения проблемы (это мое текущее «лучшее» решение).

3) Обратитесь к сообществу разработчиков, чтобы узнать, смогу ли я узнать достаточно о больших базах данных, чтобы мы могли пройти до тех пор, пока не смогу внедрить решение №1.

Буду очень признателен за любую помощь или любые книги, которые вы порекомендуете.

Ответы [ 3 ]

1 голос
/ 29 июня 2009

Вот несколько мыслей, но ни одна из них не является быстрым исправлением:

  1. Разработка архивной стратегии для данные в ваших больших таблицах. Создайте таблицы с аналогичными форматами существующая транзакционная таблица и скопировать данные в эти таблицы на периодической основе. Если вы можете получить покончить с выбиванием данных из система TX, то хорошо.

  2. Разработка реляционного хранилища данных хранить большие наборы данных, в комплекте со звездными схемами состоящий из таблиц фактов и размеры. Для введения в этот подход не лучше книга (имхо) чем ральф кимбалл Набор инструментов хранилища данных .

  3. Для анализа рассмотрите возможность использования MS Аналитические услуги для предварительно агрегировать эти данные для быстрого выполнение запроса.

  4. Конечно, вы также можете посмотреть на Ваша стратегия индексации в существующая база данных. Будь осторожен с любые изменения, как вы могли бы добавить индексы это улучшило бы запросы на стоимость вставки и транзакции производительность.

  5. Вы также можете исследовать разбиение в SQL Server.

  6. Не расстраивайтесь по поводу привлечения DBA на контрактной основе, чтобы помочь ...

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

Конечно, вам нужно будет приобрести некоторые новые навыки для работы с этими объемами данных. Что бы вы ни решили сделать, сначала сделайте резервную копию!

Еще одна вещь, которую вы должны сделать, - убедиться, что ваш ввод / вывод правильно распределен по максимально возможному количеству шпинделей. Ваши файлы данных, файлы журналов и файлы данных базы данных sql server temp должны находиться на отдельных дисках с большой системой баз данных.

0 голосов
/ 29 июня 2009

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

Присоединение к таблице записей 100 миллионов не должно ставить сервер баз данных на колени. Клиенты моей компании делают это много сотен (возможно, тысяч) раз в минуту в нашей системе.

0 голосов
/ 29 июня 2009

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

Я считаю, что Microsoft предлагает аналогичную услугу. Вы можете спросить.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...