Если в результате перемещений файлов базы данных tempdb Вы доигрались до того, что служба MS SQL Server больше не запускается, то скорее всего у вас проблемы либо с диском, куда указали файл, либо с размерами tempdb, либо с правами на доступ.
Если разобраться по логам скуля с этой проблемой вы не смогли, то надо вернуть назад или в другое место файлы.
Для этого запустите службу в ограниченном режиме (в командной строке)
NET START MSSQLSERVER /f /T3608
Если у Вас не экземпляр по умолчанию, а именованный, то строка будет иметь вид
NET START MSSQL$instancename /f /T3608
Вызовите через командную строку подключение под учетной записью Windows, имеющей права SYSADM (в моем случае это будет administrator)
SQLCMD -s COMPUTERNAMEadministrator
Теперь снова измените путь
USE master
GO
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = ‘C:Program FilesMicrosoft SQL ServerMSSQL10_50.MSSQLSERVERMSSQLDATA empdb.mdf’)
GO
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = ‘C:Program FilesMicrosoft SQL ServerMSSQL10_50.MSSQLSERVERMSSQLDATA empdblog.ldf’)
GO
У Вас пусть может отличаться. Ну вот, собственно, и все, теперь рестартуйте службу, и все заработает.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Дааа 🙂 Писал своим подобную инструкцию, когда перенесли tempdb на RAM-диск. Всё, как полагается: сделали на RAM-диске папку TEMP, положили туда tempdb, но вот незадача — после перезагрузки сервера папка-то сама не создаётся 😀
По статье бы сделал два дополнения:
1) Как узнать, что не запускается именно из-за tempdb — тут надо лезть в журнал событий Windows
2) Лучше предварительно остановить службу сервера 1С:Предприятия, потому что если 1Ска уже успеет подключиться к MS SQL, то вы со своим SQLCMD пролетаете 🙂
В нашем случае нельзя останавливать сервер 1С, потому как есть боевые базы, которые работают на другом SQL и должны продолжать работать. Тогда начинаются пляски с песнями:
1: остановил SQL, 2: запустил SQL, 3: запустил SQLCMD, 4: Успех? — работаем, нет? — goto :1.
(1) Расскажите, пожалуйста, подробнее о вашем опыте с tempdb на RAM-диске
(2) B2B,
В целом всё довольно просто, потому ограничусь возникавшими проблемами:
1) нужно сразу создать дополнительную файловую группу на физическом диске. Это нужно для того, чтобы в случае, если RAM-диск переполнится, то запросы могли продолжать выполняться. В противном случае пользователи быстро увидят сообщение от MSSQL.
2) если хотите на RAM-диске создавать папку, как мы, то надо либо
(а) добавить в автозапуск BAT-ник по созданию папки, чтобы он выполнялся до запуска MS SQL
(б) мы просто отключили перезагрузку сервера, потому как вариант (а) надо было согласовывать с админами и тому подобное
3) в MS SQL Management Studio в свойствах базы tempdb будет показываться неестественный размер базы (вплоть до отрицательного) — это какая-то особенность работы на RAM-диске, проблем из-за этого не возникает.
4) в случае, если возникла ситуация из пункта 1, то это может резко и заметно сказаться на производительности. у нас это вылечилось просто увеличением размера RAM-диска. у нас на сервере SQL 280 ГБ оперативки, мы можем себе позволить RAM-диск до 40 ГБ при базе в 500 ГБ.
Точное название проги сейчас не скажу, в офисе буду — посмотрю. Помню, что баран нарисован на логотипе 🙂
(3) baton_pk,
а не достаточно просто еще один файл добавить в текущую файловую группу?
(3) baton_pk,
а какой RAM-диск вы используете?
(4)
простите негодяя, ночь, жена, дети…
конечно же проще просто добавить файл в файловую группу.
(5) прогу завтра уточню. помню только, что с бараном. у нас её админы ставили, потому я не запомнил.
некоторые RАМ-диски не понравились, например этот
пришлось отключить
(5)
Вот этот у нас стоит:
Бесплатная. Пока что бед мы с ней не ведали.
(5) такую же штуку делал… SuperSpeed RamDisk Pro. Не бесплатная конечно, но есть серверная версия вызывает хоть какое-то доверие…
Правда всё равно проблемы при перезагрузке сервера возникают :(. «Разорились» в итоге на IO Accelerator. Разница особо не ощутима… программку же успешно используем на отдельном сервере для «монопольного восстановления последовательности» :).
p.s. сам «рецепт» из статьи давно пора уже на ИТС 1С-овцам разместить… а то чем только люди не занимаются получив подобную ошибку…
(10) comol, так оно так и будет, сначала пишу я, потом 1с )))
(9) comol, SuperSpeed используем для крупного клиента, работает отлично, только стоит хорошо
(3) baton_pk,
Привет опыт бесценный, не мог бы ты подробно расписать порядок создания файловой группы.
Правильно ли я понимаю, что если temp.db вдруг съел всю ram память, то он начинает использовать вторую файловую группу?
так самого главного не написали )
хорош ли «выхлоп» от переноса tempdb ?
в моем случае имею сервер с 30 гб ОЗУ, из них 20 не особо то используются,
баз много, пользователей тоже
tempdb показывает размер порядка 600 мб (мдф + лог)
как думаете стоит заморачиваться с переносом ?
(14) так весь «выхлоп» и заключается в том, что освобождается место от гигантских объемов tempdb, переносом tempdb.mdf и tempdb.ldf на другой диск (а то и сами базу и журнал — еще по разным дискам можно разнести).
Скорость здесь не особо повысится — разве что сами диски будут существенно быстрее, типа SSD (для чего, например, и заморачиваются с переносом на RAM диск).
В вашем случае вообще беспокоится не о чем — 600 Мб tempdb — это критично, если диск размером в 1ГБ )
А так — tempdb.mdf может достигать и нескольких десятков ГБ, и сотен ГБ (да еще размер журнала tempdb.ldf тоже не маленький), вот в этом случае и занимаются отделением tempdb и переносом на более емкие диски.
По прошествии времени могу поделится наблюдениями — то что я описывал относилось к второстепенному серверу. Решился перенести на основном
для начала надо понять что происходит на сервере для этого используем монитор ресурсов и т.п. он показывает нагрузку на диск — заморачиваться стоит, если эта нагрузка велика, плюс наблюдаем за средней очередью диска в утилите perfmon, в идеале она должна «болтатся» не больше десятых (0.1)
от чего это зависит нагрузка понять конечно не просто, есть подозрение что нагрузка идет при большом количестве пользователей и обилии запросов к виртуальным таблицам, в теории файл этот виртуальные таблицы и обслуживает, почему это надо делать на диске, а не в памяти, для меня загадка
на практике у меня
база объемом 200+ ГБ
tempdb 16ГБ — вот этот размер тоже не понятно откуда берется, ОЗУ менялась с 32 на 64 гб, ограничения в самом SQL сняты, ограничений по дискам ессно нет смотрим по факту что имеем то имеем опять же
пользователей около 250
в принципе, имеется избыточная оператива при 64 гб сами rphost жрут весьма скромно гигобайты, sql может расти до 30 гб, т.е. эти 16 гб можно было бы выделить и в оперативе
у меня в периоды наибольшей нагрузки идет постоянная запись/чтение порядка 20мБ — казалось бы, цифра не велика, но надо учитывать, что это чтение состоит из мелких операций у «бытовых» винтов рандомное чтение может не тянуть и больше 5мБ, серверных около 20 может быть пределом — это при том что последовательная запись/чтение более 600мБ
таким образом анализируя обращение к файлам temp.db и следует принимать решение — если оно велико толк однозначно будет
у меня после переноса на отдельный ssd очередь диска стала весьма мала до этого прыгала до единиц и десятков — есть подозрение, что именно в эти моменты происходит подвисание