Você está com sorte, se os assemblies implantados originais estiverem simplesmente ausentes, você ainda poderá exportar o binário da montagem como uma cadeia hexadecimal.
1.Abra o SSMS e navegue até Programabilidade - > Assemblies. Você deveria ver sua Assembléia Registrada, eu destaquei a minha em vermelho.
2.Cliquenamontagemecrieumscriptparaumanovajaneladeconsulta:
3.Quando você fez isso, você verá algo assim:
CREATE ASSEMBLY [Microsoft.SqlServer.Types]
AUTHORIZATION [sys]
FROM 0x4D5A90000300000004000000FFFF0000B800000000000000400000000...[snipped]
WITH PERMISSION_SET = UNSAFE
A linha com FROM 0x4D5A90000... é a montagem real codificada como uma cadeia hexadecimal grande. Veja abaixo como exportar de volta para o formato de arquivo.
Certifique-se de também script de funções, gatilhos, etc, que dependem deste assembly também. Você pode encontrá-los fazendo uma "View Dependencies" na montagem no SSMS.
Você deve ser capaz de reinicializar o servidor com impunidade porque o conjunto é armazenado e carregado de uma das tabelas de banco de dados do sistema (cujo nome não consigo lembrar da mão, mas a montagem é visível por meio do sys.assembly_files vista do sistema) e não no sistema de arquivos.
No entanto, se você não quiser dar um salto de confiança, faça a exportação como descrito acima e, em seguida, recrie em outra instância do SQL 2005 para ter certeza de que tudo está intacto.
Como exportar conjuntos registrados para arquivos
Com base em uma resposta que encontrei em este segmento você pode exportar seus assemblies registrados de volta para arquivos regulares. Se o Visual Studio foi usado para implantar o assembly, também pode haver alguns objetos de código-fonte armazenados no SQL Server, o que obviamente é um bônus. Por exemplo, quando consultei meu servidor de desenvolvimento após a implantação do VS2010, encontrei o seguinte:
SELECT * FROM sys.assembly_files
Como você pode ver, há alguns arquivos associados a SqlServerProject2 ( assembly_id = 65540 ). Podemos exportar todos eles executando este script:
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
Você precisará definir essas duas variáveis:
SET @assembly_id = 65540
SET @outputdir = 'D:\Data\Assemblies\'
O caminho @outputdir precisará estar em algum lugar em que o SQL Server tenha permissões para gravar.
Quando você executa o script, você deve acabar com um ou mais arquivos. Se você não tem todo o código fonte, então você pode sempre descompilar o assembly gerado usando o .NET Reflector.
Observação: a automação OLE (os procedimentos sp_OAxxxxx armazenados) está desabilitada por padrão no SQL Server, mas você pode ativá-la executando:
use master
go
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'Ole Automation Procedures', 1;
GO
RECONFIGURE;
GO