Restaurando banco de dados sem o arquivo de log

Um banco de dados do SQL Server 2008 sofreu com a inabilidade de um colaborador, pois é, ele foi apagado.

Conseguimos recuperar somente o MDF, que é o arquivos de dados do SQL Server. Algumas versões atrás do SQL Server, essa recuperação era bem trivial, mas no 2008 levei algumas horas para conseguir um novo banco sem ter o arquivo LDF.

Quando o assunto é banco de dados procuro logo pelo blog do Pinal Dave e achei um post em http://blog.sqlauthority.com/2010/04/26/sql-server-attach-mdf-file-without-ldf-file-in-database/ que auxiliou bastante.

No entanto, as coisas não estavam funcionando muito bem. O problema ocorria quando utilizava o método 2 que o autor indicava, que seria:

CREATE DATABASE TestDb ON
(FILENAME =N’C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDb.mdf’)
FOR ATTACH_REBUILD_LOG
GO

O SQL Server reportava um erro tentando criar o arquivo de log original buscando as informações no MDF.

Após algumas pesquisas, encontrei no blog do SqlDestiny em http://sqldestiny.com/2011/04/01/attach-a-database-without-log-file-using-for-attach_rebuild_log/ o comentário de um usuário alterando a sentença anterior de FOR ATTACH_REBUILD_LOG para FOR ATTACH_FORCE_REBUILD_LOG, ficando:

CREATE DATABASE TestDb ON
(FILENAME =N’C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\TestDb.mdf’)
FOR ATTACH_FORCE_REBUILD_LOG
GO

Dessa forma meu banco de dados foi criado e estamos aguardando o próximo desafio.

Abraço.

Anúncios

Como alterar o email principal do usuário no Office 365

Após alguns sinistros com infraestrutura, especificamente, com meus servidores que hospedam o Zimbra, decidi investigar mais a fundo o Office 365 da Microsoft para usar como solução colaborativa.

Sempre fui, e continuo sendo, um fã do Zimbra, mas a possibilidade de utilização da nuvem da Microsoft e todas as vantagens que isso trás foram decisivos.

Como trabalho em uma Instituição de Ensino, tive acesso ao serviço de forma completamente gratuita, caixas postais de 25 GB por usuário, mais antispam, antivírus, arquivamento etc. Inevitável à migração.

Depois até vou escrever um post compartilhando o processo de Federação do domínio que é bem interessante e útil.

Pois bem. Algumas contas durante o processo de sincronização dos meus DCs (Domain Controller) locais com os DCs no Windows Azure apresentaram uma inconsistência no campo chamado “Email principal do usuário”. Nesse local deveria estar armazenado o domínio qualificado, por exemplo, empresa.com.br. No entanto, o valor que estava armazenado era empresa.onmicrosoft.com, que é o domínio criado no Office 365 na hora do cadastro de um novo domínio. E no alias (Outros endereços de email) estava o valor do domínio empresa.com.br, ou seja, os valores estavam invertidos.

O problema dessa inversão de valores é que o email errado (empresa.onmicrosoft.com) aparecia como principal quando a lista de contatos era consultada e eu não queria que o email .onmicrosoft.com fosse publicado nas mensagens.

Como os usuários são todos federados, a mudança necessitava ser feita no AD local. Encontrei então o post de Geert Baeke em http://blog.baeke.info/2012/06/24/office-365-identity-management-with-dirsync-without-exchange-server-on-premises/ que me ajudou bastante.

Estava quase corrigindo o problema, quando o telefone toca, era o suporte da equipe do Office 365 da Microsoft me arguindo a respeito de um chamado que abri. Realmente, no início da manhã, entrei no painel do Office 365 e reportei o problema por chamado. Os caras ligaram!!! Mais do que ligar, o cara sabia exatamente qual era meu problema e prontamente apresentou a solução, que era a mesma do post acima mencionado.

A Microsoft merece um graúdo PARABÉNS!

Vamos aos fatos:

1) Utilizando o ADSI Edit procure pelo objeto (usuário) que necessita fazer a troca de valores dos emails;

2) Clicando o botão direito selecione a opção Propriedades, procure pelo campo proxyAddresses e clique em Edit;

3) Digite: SMTP:usuario@empresa.com.br e clique em Add. SMTP tem que ser maiúsculo;

4) Agora digite: smtp:usuario@empresa.onmicrosoft.com e clique em Add. smtp agora minúsculo;

5) Feche tudo clicando em OK.

Pronto, agora é esperar a replicação. Mas se quiser forças às atualizações, siga os passos:

1) No seu servidor que está com o DirSync (ferramenta de migração do AD local com o Azure) procure pelo arquivo DirSyncConfigShell.PSC1 que deve estar em C:\Program Files\Microsoft Online Directory Sync e clique nele;

2) Uma janela de Power Shell será aberta, digite: Start-OnlineCoexistenceSync;

3) Abra o Forefront Synchronization Service Manager do Forefront Identity Manager 2010 que está em C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell com o nome de miisclient.exe e observe que em Operations o processo estará em execução;

4) Ao final da replicação o usuário no Office 365 estará com os valores corretos.

Obrigado pela atenção e forte abraço.