вторник, 22 октября 2019 г.

Восстановление базы MS SQL 7 после физического разрушения носителя.

Исходные данные: 

Есть Windows 2000 (рабочее место доктора в составе флюрографа "Ренекс") с физически развалившимся диском, на котором живет (или жила) база в 380 с небольшим тысяч записей (по числу снимков в соотв. каталогах). 

Меняем диск, копируем все что скопировать можно и начинаем танцы с бубном Собственно нас интересует только база Hospital (живет в d:\Database), остальное можно как-то скопировать из дистрибутива или запустить установку на виртуалке, ценного там нет ничего. Имеем базу в состоянии SUSPECT...
Первоисточники
http://ibnjd.narod.ru/ - тут много чего полезного лежит в смысле дистрибутива.
https://www.sql.ru/faq/faq_topic.aspx?fid=123 - вот тут есть здравое зерно, поскольку в документации никак не отыскать никакой информации о флагах состояния БД (да еще бы быть уверенным что это соответствует именно установленной версии), то проще создать новую базу (ради флагов) и подменить файлы. Следует так же иметь ввиду небольшое отличие в синтаксисе и функциональности. SQL2000 реально много лучше SQL7.

Смотрим лог - самый верх, там версия SQL - у нас 7SP4. На виртуалку (Win XP) ставим ее же. На просторах все есть. При установке указываем авторизацию средствами ОС.

Собственно из всей установки нам нужен файл C:\MSSQL7\BIN\ISQLW.EXE и dll-ки, которые он за собой потянет. Скорее всего можно обойтись и без установки, просто понадергать из инсталляции... - не пробовал. Это QA. В отличие от sql2000, enterprise manager в sql7 не умеет подключать и отключать базы, что делает его бессмысленным. Копируем isqlw.exe в  d:\mssql7\binn\  и пробуем запустить, подключаемся к нашему серверу (имя смотрим в sqlmanger.exe, у нас SRVDOC).

Пробуем тестовый запрос 
SELECT * FROM sysdatabases ;
- должны получить флаги всех таблиц.

Отцепляем базу hospital и переносим файлы куда-либо на хранение.
sp_detach_db 'Hospital'

Создаем  точно такую же пустую базу в том же каталоге.

CREATE DATABASE Hospital
ON 
( NAME=hospital, 
FILENAME ='D:\Database\hospital.mdf' )
LOG ON
( NAME=hospital_log,
FILENAME ='D:\Database\hospital_log.ldf' )
GO

Выполняем тестовый select и смотрим флаг состояния новой чистой БД (1077936141).

Останавливаем SQL
Стираем вновь созданные файлы d:\Database\*.*
Копируем сохраненный ранее файл hospital.mdf на место только что стертых двух.
Запускаем SQL
Подключаемся к нему при помощи QA и продолжаем

use master;
EXEC sp_configure 'allow updates', 1
reconfigure with override
go

Меняем флаг
USE master;
UPDATE sysdatabases SET STATUS=32768 WHERE  name = 'Hospital';

Перезапускаем SQL, подсоединяемся и продолжаем.

Создаем новый log-файл.
DBCC REBUILD_LOG('Hospital', 'D:\Database\hospital_log.ldf')

И собственно восстанавливаем базу.
USE master
GO
sp_dboption 'Hospital', 'single user', 'true';
GO
USE Hospital
GO
DBCC CHECKDB (Hospital, REPAIR_ALLOW_DATA_LOSS);
GO

Если нет ошибок (если есть, можно и повторить)
sp_dboption 'Hospital', 'single user', 'false'
GO
USE master
EXEC sp_configure 'allow updates', 0
go
reconfigure with override
go

Перезапускаем сервер. ВСЕ!




понедельник, 14 октября 2019 г.

Windows 2008R2 и отставание времени

Исходные данные: 

Есть Windows 2008R2 сервер. Живет на виртуалке, как ему и положено. Постоянно (в зависимости от общей нагрузки) на нем отстает время. За 8 часов примерно минут на 40... Что удалось выяснить... Полноценная поддержка ntp на данной ОС не обнаружена. Есть только синхронизация раз в сутки, нечто вроде ntptime. Выполняется по расписанию, легко обнаруживается в соответствующей ветке системных заданий - Microsoft - TimeSyncronization. 

Ничего лучше не придумалось, чем создать задание w32tm /resync с интервалом запуска 10 минут. Собственно все!