Зачем мне отключать базу данных?

15

По каким причинам и в каких ситуациях вы используете ALTER DATABASE dbName SET OFFLINEфункцию «Отключить» .

Какие задачи вы можете выполнять с автономной базой данных? Какие задачи вы можете выполнять только с автономной базой данных?

sql-server

— Грег Б
источник

16

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

— mfinni
источник

4

+1 или другой диск / папка / SAN ...

— Крис С

Это единственное использование для «офлайн»?

— Грег Б

5

Нет, я могу думать о других причинах. Представьте, что у вас есть несколько баз данных для нескольких приложений. Одним из таких приложений является обновление интерфейсного приложения (веб-приложение, клиент, который знает.) Вы хотите отключить доступ к базе данных кем-либо во время обновления, но не хотите отключать весь сервер из-за других баз данных. Это может быть причиной, чтобы отключить его. Я уверен, что ваше воображение может придумать и другие причины.

— mfinni

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

— Грег Б.

2

Грег Б. - я специально сказал, обновляя интерфейс, а не саму БД. В описанном мною сценарии БД остается без изменений. Он будет переведен в автономный режим, чтобы никто не мог получить к нему доступ во время перехода.

— mfinni

18

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

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

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

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

— squillman
источник

2

Мне нравится идея офлайн до удаления

— Грег Б.

8

То же самое. У меня есть четыре тысячи баз данных в нашей предварительной среде. Иногда трудно понять, кому что принадлежит. Отключение и ожидание визга иногда является единственным вариантом.

— Майкл Грин

6

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

— joeqwerty
источник

2

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

— Шон Ховат

Вы даже не можете переименовать его!

— Дима Фомин

0

Моя главная причина, которую я должен продавать АБД чаще, чем я хотел бы перечислить ...

«SAN нуждается в ремонте ... и нет, я не могу просто заменить диск в горячем режиме, неисправна объединительная панель / контроллеры».

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

Таким образом, я отключаю экземпляры SQL перед тем, как перевести SAN в автономный режим, а затем возвращаю их по одному за раз, чтобы они не оспаривали ресурсы - первый работающий экземпляр забирает все ресурсы кластера и становится узлом Active DB, последующие экземпляры запускаются как пассивные узлы.

— Джордж Эрхард
источник

-3

Есть много причин, почему вам нужно сделать это ..

Например,

consider changing or upgrading the actual database program/binary...
consider changing or upgrading the schema or tables..
consider changing or upgrading index's..

Самый важный момент ..

Is taking a backup.. to get a perfect snapshot in time..

(в некоторых БД вы просто создаете блокировку для всех таблиц)

— Arenstar
источник

+1, также более старая СУБД для дефрагментации или сжатия БД.

— Крис С

1

re: «изменение или обновление схемы», из книг в сети «OFFLINE База данных закрыта, полностью закрыта и помечена как отключенная. База данных не может быть изменена, пока она находится в автономном режиме». Как вы можете обновить схему в этой ситуации?

— Грег Б

Извините ... я пытался внести изменения в неактивную базу данных. Я последователь MySQL, я предполагал, что обновление будет выполняться для базы данных, помеченной как автономная, поэтому у нее не было проблем с параллелизмом ни с чем, кроме необходимых изменений. Может быть, мы можем оставить это потом ..: D

— Arenstar

2

Знаете, реальные базы данных поддерживают реальные резервные копии. Вам не нужно брать ничего, кроме игрушечной линии, чтобы сделать идеальное во времени последовательное резервное копирование. БД, требующий блокировки или какого-то другого глупого механизма, - игрушка. В самом деле. Все основные базы данных не имеют проблем с полным резервным копированием, согласованным, в то время как в интенсивном использовании.

— TomTom