Мы унаследовали устаревшую базу данных SQL 2005. Две сборки были настроены для использования триггерами в одной из баз данных (ай). Папка / файлы были удалены по ошибке. Они были установлены предыдущим сотрудником из папки на его рабочем столе и не были проверены в системе контроля версий (двойная ошибка). Теперь, когда dll больше нет, мы беспокоимся о перезагрузке. SQL 2005 копирует / переименовывает / сохраняет эти библиотеки таким образом, чтобы перезагрузка сервера не создавала проблем?
Вам повезло: если исходные развернутые сборки просто отсутствуют, вы все равно можете экспортировать двоичный файл сборки в виде шестнадцатеричной строки.
1. Откройте SSMS и перейдите к Программируемость -> Сборки. Вы должны увидеть свою Зарегистрированную Ассамблею, я выделил мою красным.
2. Щелкните сборку правой кнопкой мыши и запишите ее в новое окно запроса:
3. Когда вы это сделаете, вы увидите что-то вроде этого:
CREATE ASSEMBLY [Microsoft.SqlServer.Types]
AUTHORIZATION [sys]
FROM 0x4D5A90000300000004000000FFFF0000B800000000000000400000000...[snipped]
WITH PERMISSION_SET = UNSAFE
Линия с FROM 0x4D5A90000...
- это фактическая сборка, закодированная в виде большой шестнадцатеричной строки. См. Ниже, как экспортировать обратно в формат файла.
Убедитесь, что вы также используете сценарии для любых функций, триггеров и т. Д., Которые также зависят от этой сборки. Вы можете узнать их, выполнив «Просмотр зависимостей» сборки в SSMS.
Вы должны иметь возможность безнаказанно перезагружать сервер, потому что сборка хранится и загружается из одной из таблиц системной базы данных (чье имя я не могу вспомнить, но сборка видна через sys.assembly_files
системный вид), а не в файловой системе.
Однако, если вы не хотите совершать перезагрузку, выполните экспорт, как описано выше, а затем воссоздайте на другом экземпляре SQL 2005, чтобы убедиться, что все в порядке.
На основании ответа, который я нашел в эта тема вы можете экспортировать зарегистрированные сборки обратно в обычные файлы. Если для развертывания сборки использовалась Visual Studio, на сервере SQL также могли бы храниться некоторые объекты исходного кода, что, конечно, является бонусом. Например, когда я запросил свой сервер разработки после развертывания из VS2010, я обнаружил следующее:
SELECT * FROM sys.assembly_files
Как видите, есть несколько файлов, связанных с SqlServerProject2
(Assembly_id = 65540). Мы можем экспортировать их все, запустив этот скрипт:
DECLARE @assembly_id int, @name nvarchar(260), @content varbinary(MAX)
DECLARE @ObjectToken INT, @outputdir nvarchar(20)
-- Get assembly id from querying sys.assembly_files
SET @assembly_id = 65540 -- IMPORTANT: SET THIS VALUE
SET @outputdir = 'D:\Data\Assemblies\' -- AND THIS PATH
DECLARE assy_cursor CURSOR FOR
SELECT name, content
FROM sys.assembly_files
WHERE assembly_id = @assembly_id
OPEN assy_cursor
FETCH NEXT FROM assy_cursor INTO @name, @content
WHILE @@FETCH_STATUS = 0
BEGIN
SET @name = @outputdir + REPLACE(@name, '\', '-')
print 'Saving: ' + @name
EXEC sp_OACreate 'ADODB.Stream', @ObjectToken OUTPUT
EXEC sp_OASetProperty @ObjectToken, 'Type', 1
EXEC sp_OAMethod @ObjectToken, 'Open'
EXEC sp_OAMethod @ObjectToken, 'Write', NULL, @content
EXEC sp_OAMethod @ObjectToken, 'SaveToFile', NULL, @name, 2
EXEC sp_OAMethod @ObjectToken, 'Close'
EXEC sp_OADestroy @ObjectToken
FETCH NEXT FROM assy_cursor INTO @name, @content
END
CLOSE assy_cursor
DEALLOCATE assy_cursor
Вам нужно будет установить эти две переменные:
SET @assembly_id = 65540
SET @outputdir = 'D:\Data\Assemblies\'
В @outputdir
path должен быть где-то, куда SQL Server имеет разрешения на запись.
Когда вы выполняете сценарий, вы должны получить один или несколько файлов. Если у вас нет всего исходного кода, вы всегда можете декомпилировать полученную сборку с помощью .NET Reflector.
Примечание: OLE-автоматизация ( sp_OAxxxxx
хранимые процедуры) по умолчанию отключен в SQL Server, но вы можете включить его, выполнив:
use master
go
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'Ole Automation Procedures', 1;
GO
RECONFIGURE;
GO