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

Файлы tempdb SQL Server 2005 перемещены на недопустимый (SSD) диск. Как проверить диск или как вернуть файлы?

32-разрядная версия SQL 2005 для разработчиков, все последние пакеты обновления

Windows Server 2003 Standard 64x, все последние обновления

Привод Fusion IO

Мы установили новую изящную SSD-карту на 80 ГБ на нашем сервере разработки, запустили ALTER TABLE в tempdb (начальный размер 10 ГБ), чтобы переместить эти файлы на новый диск, остановили SQL Server, а затем попытались перезапустить его ... но теперь SQL не будет start с сообщением «Произошла ошибка службы: 1814». Sys.Messages имеет 1814 как «Не удалось создать tempdb. Возможно, у вас недостаточно свободного места на диске. Освободите дополнительное дисковое пространство, удалив другие файлы на диске tempdb, а затем перезапустите SQL Server. Проверьте наличие дополнительных ошибок в журнале событий, которые могут указывать на почему файлы tempdb не могут быть инициализированы. " В журнале событий приложений указано: «FCB :: Open: Ошибка операционной системы 5 (доступ запрещен.) Произошла при создании или открытии файла« F: \ TempDB ». Диагностируйте и исправьте ошибку операционной системы и повторите операцию». Служба SQL настроена для работы в качестве учетной записи домена, и эта учетная запись является локальным администратором на поле.

Я предполагаю, что нужно где-то настроить какой-то скрытый бит, который «разрешает» использование нового диска SQL Server. Есть идеи, что это может быть?

Что я действительно хотел бы сделать, так это сказать SQL не создавать файлы tempdb на этом диске ... но для этого вам нужно выполнить ALTER DATABASE для перемещения файлов, но мы не можем запустить службу для выдачи этого команда. Как переместить файлы tempdb для экземпляра SQL Server 2005 (именованного) без фактического запуска экземпляра? (Это SQL 2005, поэтому я не могу просто взломать таблицы в master db, как это было в 2000 или 7.0.)

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

Похоже, проблема возникла, когда администратор (не я, честно!) Ввел неправильные пути для файлов, хотя мы никогда не узнаем наверняка. Ему удалось как-то исправить это, запустив SQL с ключами -c и -f и переместив файлы в нужные места.

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

ЧИТАТЬ. Сообщение об ошибке.

Он говорит:

В журнале событий приложений указано «FCB :: Open: Ошибка операционной системы 5 (доступ запрещен). При создании или открытии файла« F: \ TempDB ».

Вы можете попытаться заставить кого-нибудь объяснить вам "Доступ запрещен";)

Я предполагаю, что нужно где-то настроить какой-то скрытый бит, который «разрешает» использование нового диска SQL Server. Есть идеи, что это может быть?

Да, их называют охраной. NTFS имеет довольно подробную безопасность на дисках. Пользователь, использующий SQL Server (зависит от того, как вы его установили), не имеет необходимых разрешений на диске для создания файлов. В SQL Server нет ничего "особенного" - это проблема с простыми, примитивными, обычными разрешениями файловой системы.

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

Что ж, помимо того, что вы являетесь локальным администратором (не имеет отношения к делу, НАСТОЯТЕЛЬНО не рекомендую - серьезно, строго) - проверьте, может ли эта учетная запись действительно создать файл, о котором идет речь (или файл с аналогичным именем). Если нет (разрешения файловой системы), это проблема. Моя ставка.

Тем не менее, я бы вообще спросил об использовании SSD для файла tempdb. Серьезно тратить деньги в 99% случаев.

звучит так, как будто вы залили свою систему dbs. ВСЕГДА резервное копирование системных баз данных ... они могут пригодиться позже в такие моменты.

http://support.microsoft.com/kb/943635

попробуйте это, чтобы снова запустить sql - затем просто выполните прикрепление с помощью db.

затем, конечно, убедитесь, что ОС распознает новый диск, что он все отформатирован и готов к работе - и убедитесь, что идентификатор, под которым вы запускаете sql, может получить доступ к этому диску.

надеюсь, что это поможет, удачи!

По поводу бэкапов системных баз: master, model, msdb да. Tempdb перестраивается каждый раз при перезапуске службы ядра базы данных, поэтому я бы пропустил tempdb.

Это может быть связано с известной ошибкой: когда вы перемещаете tempdb с помощью ALTER DATABASE, SQL-сервер ищет указанное свободное пространство (в вашем случае 10 ГБ) на исходном диске, а не на вашем новом SSD-диске. Поэтому, если на исходном диске нет 10 ГБ, он выйдет из строя. Что вам следует сделать, так это сначала переместить базу данных на новый SSD-диск, используя небольшой размер (например, 1 МБ), а затем снова изменить его размер до желаемого размера (10 ГБ).

Брент Озар объяснил это Вот лучше.

не уверен, что вы уже решили это, но вот ... похоже, что SQL ищет папку «F: \ TempDB» для создания файлов данных при перезапуске. F: \ управляет новым приводом Fusion-IO? Если да, то создали ли вы на диске папку «TEMPDB» с соответствующими разрешениями, чтобы SQL мог получить к ней доступ?

SQL будет напрямую пытаться получить доступ к папке и не будет создавать папку, если она не существует ... вероятно, в этом ваша проблема! Надеюсь это поможет.

С уважением Чираг