Наша текущая рабочая среда базы данных содержит около 10 баз данных с аналогичным управлением. Наше агентство только что приобрело и устанавливает новые пазы для лезвий и хочет переместить мою базу данных в новый экземпляр (оставив остальные 9 на другом). Это решение было принято одним из наших ИТ-специалистов, а не администратором баз данных. Я менеджер проекта, а не администратор баз данных, но я знаю достаточно, чтобы не обязательно иметь хорошее представление об этом решении, и я призываю наш ИТ-отдел принять правильное решение, основанное на том, что лучше всего для базы данных. Наш ИТ-отдел заявил, что хранить все яйца в одной корзине нехорошо, а также заявил, что моя база данных содержит «нормативные данные», поэтому она должна находиться в отдельном экземпляре.
Пару истин: - Ни одна из баз данных в текущем экземпляре не является базой данных OLTP и не является хранилищем данных - Моя база данных в настоящее время присоединяется / просматривается к нескольким другим базам данных в производственной среде
Итак, мои вопросы следующие:
Я неправильно игнорирую утверждение о яйцах в корзинах? (привет, вот почему у нас есть планы обслуживания / планы аварийного восстановления). Упомяну, что нормативные данные есть и в других базах данных.
Какие вопросы мне нужно задать, чтобы определить, правильное ли это решение? (Друг DBA упомянул, что если соглашение об уровне обслуживания указанной базы данных радикально не отличается от других, то почему они хотят это сделать?)
Я провел небольшое исследование связанных серверов. Какие аргументы я должен привести по поводу того, что у меня есть настройки представлений, которые в настоящее время полагаются на данные из других БД?
Из того, что я читал, в вашей среде нет «официального» администратора баз данных. На таком расстоянии сложно сделать много конкретных заявлений, но вот некоторые вещи, над которыми я бы обдумывал.
Во-первых, вполне возможно, что ИТ-персонал прав и данные должны быть на другом сервере по какой-то нормативной причине. Иногда правила есть правила. Они могли быть согласованы лицами в правительстве (или правовой системе) безотносительно того, как они могут быть технологически имплементированы. Даже если правила могут не иметь 100% «логического» смысла, вы не собираетесь их менять.
Кроме того, в качестве своего рода всеобъемлющей вещи я бы предположил, что, пока производительность не пострадает, а время безотказной работы, аварийное восстановление и другие элементы, покрываемые SLA, не окажутся отрицательными, это действительно будет шея ИТ-персонала. блок нарезки. Вы не несете ответственности за соблюдение нормативных требований (или, я полагаю, вас бы научили лучше разбираться в правилах), а ИТ-персонал отвечает за соблюдение требований. Если с приложением что-то пойдет не так или они нарушат какое-то нормативное правило, им придется смириться с последствиями. Вы можете сказать: «Айтишники сказали мне, что все будет хорошо». (Если в системе возникнут какие-либо проблемы на новом сервере, я обязательно выясню, возникла бы проблема, если бы база данных находилась на старом сервере.)
Как администратор баз данных со стажем, который работал над множеством проектов консолидации, вам, как правило, нужно меньше экземпляров, а не больше. (Я не говорю об экземплярах dev / test / qa / production; здесь мы говорим только о производстве.) Легче управлять меньшим количеством экземпляров, и это снижает затраты на лицензирование. Иногда некоторые люди влюбляются в идею большого количества серверов, считая, что чем больше, тем лучше. «100 серверов с 1 базой данных на каждом» чем-то лучше, чем «100 баз данных на 1 сервере».
Собираются ли они перенести эти другие базы данных с нормативными данными на блейд-серверы или ваша была выделена? Если будет перемещено больше баз данных, почему ваша первая?
Какой тип SLA у вас есть для вашей базы данных? Могут ли лезвия справиться с этим? Как они это узнали? Если старый сервер сгруппирован, кластеризованы ли новые блейды? Время безотказной работы будет таким же? Или лучше? Хранилище будет таким же?
Существуют ли внешние отчеты или приложения, которые «знают», что все эти базы данных находятся в одном экземпляре? Как насчет баз данных MS Access или таблиц Excel, которые извлекают данные? Да, такого рода вещи должны быть скрыты за представлением или хранимой процедурой, но я видел много случаев, когда этого не было. Вы же не хотите обнаруживать, что вам нужно переделывать код приложения после перемещения базы данных. Любая такая работа должна быть включена в усилия по перемещению базы данных.
С другой стороны, возможно, что «ИТ-персонал» недостаточно знает о SQL Server, чтобы чувствовать себя комфортно, используя функции SQL Server (логины, роли, разрешения, шифрование, именованные экземпляры и т. Д.), Чтобы должным образом разделить эти «нормативные требования». данные "всего в одном экземпляре. Вы можете смотреть на это как на «ИТ-персоналу нужно больше обучения / кому-то нужно купить администратора базы данных» или как на «ИТ-персоналу нужно чувствовать себя комфортно, используя то, что они уже знают, чтобы соблюдать правила». Обе точки зрения являются разумными, со всеми плюсами и минусами.
Если на текущем сервере есть проблемы с производительностью, ИТ-персонал может рассчитывать улучшить ситуацию, переместив базу данных на другой сервер. Это может быть верно по крайней мере для некоторых функций конкретной базы данных, но зависимости между базами данных могут быть очень проблематичными. Производительность запросов к связанному серверу не будет соответствовать производительности локальных запросов из-за задержки в сети, сниженной способности правильно оптимизировать запросы и способа, которым иногда выбираются данные. Иногда производительность в порядке, иногда нет. Лучший способ узнать об этом - протестировать свой код, прежде чем вы начнете работать на новом сервере. Как только вы перейдете на новый сервер, вам будет труднее что-либо сделать с неэффективными запросами, и это не то, чем вы хотите удивляться. Я видел, как люди сталкивались с этим в прошлом. Обычно ответ заключается в копировании данных с удаленного сервера на локальный сервер, обычно с помощью SSIS или связанного сервера. Это дополнительная работа, и могут возникнуть проблемы с «устареванием» данных.
Кроме того, связанные серверы могут оказаться дырами в безопасности, если их неправильно настроить. Если вашу ИТ-команду в первую очередь беспокоит доступ к нормативным данным, это также должно беспокоить их.
Если у базы данных есть зависимости от других баз данных, все они являются частью одной системы. Перенос вашей базы данных на другой сервер повысит вероятность того, что система выйдет из строя, потому что есть еще что-то, что может дать сбой.
Яйца и корзины - не лучшая метафора, хотя ее часто используют. Яйца не зависят друг от друга. Базы данных могут зависеть друг от друга. Взаимосвязанные базы данных следует рассматривать как систему. Перемещение одной базы данных на другой сервер приведет к сбою система баз данных более вероятно, потому что есть больше вещей, которые могут выйти из строя.
Тогда возникает вопрос: «Если вы отключите одну из этих баз данных наугад, как это повлияет на всю систему?» IOW, что произойдет, если старый сервер выйдет из строя? Что произойдет, если новое лезвие выйдет из строя? Если вся компания перестает работать, если остальные девять баз данных отключены, имеет ли значение, работает ваша база данных или нет?
Моя база данных в настоящее время объединяет / просматривает несколько других баз данных в производственной среде.
Итак, как это будет работать? Связанные серверы? Это создаст ОЧЕНЬ много трафика в сети. Поведение запроса (поведение просмотра) может резко измениться.