Ontem foi disponibilizado o link do SQL Server 2012 RC0 e claro que vou instalar para iniciar alguns testes.

Erro 0x85640004

Porem, sempre nesta tela ocorria o erro acima ao escolher um usuário para o Distributed Replay Controller, que é uma das novas features com o objetivo de fazer testes de workload:

A mensagem do erro: “There was a failure to validate setting CTLRUSERS in validaton function ValidateUsers.”

A solução é deixar sem escolher usuários, seja pelo botão Add Current User ou Add… pois o erro ocorrerá da mesma forma.

Se desejar inserir ou alterar o usuário padrão siga os passos deste paper: http://msdn.microsoft.com/en-us/library/gg471531(SQL.110).aspx

.NET Framework

Outro problema ao instalar é a solicitação do SP1 do .NET Framework 3.5:

Se você está utilizando o Windows 7 ou Windows 2008 R2 com SP1 o .NET Framework não aceita a instalação da versão 3.5, pois estes dois sistemas operacionais já possuem a versão 3.5.1 embutida.

Neste caso a solução é abrir o Server Manager do Windows e instalar a Feature, ou pelo Adicionar e Remover do Windows 7:

Como o framework embutido nestes dois SOs é mais recente ignore a mensagem de erro do SQL e após a instalação da feature clique em Rerun e continue a instalação.

Um situação não muito comum, mas que já me aconteceu no passado e ontem novamente é a colocação da etiqueta de código de barras em um tape depois deste já ter sido utilizado.

Nota: Este tópico também se aplica ao DPM 2007, mas neste caso é necessário mudar o nome da instância no comando.

SINTOMA

Após colocar um novo barcode ou retirar o que já existia o tape aparecerá na lista como “SUSPECT” e receberá alertas de mal funcionamento na unidade de fitas.

CAUSA

Ao utilizar uma fita que não tenha uma etiqueta de barcode o DPM gera um numero identificador na fita, chamado de OMID (on-media ID) e registra esse no banco de dados SQL Server.

Ao colocar ou substituir a etiqueta com o barcode o DPM fica com os dados de backup duplicados e passa a entender que se trata de outra fita, com os mesmos backups. Com isso a fita passa a ficar como SUSPECT.

SOLUÇÃO

O mais óbvio é colocar os barcodes ANTES de utilizar as fitas.

Porem, se ocorreu o acima execute o comando abaixo:

osql -E -S localhost\MSDPM2010 -d DPMDB -Q "UPDATE tbl_MM_ArchiveMedia SET IsSuspect = 0"

Este comando irá executar uma query no SQL Server resetando o flag “IsSuspect” de todas as fitas para falso, o que gerará outro estado no console do DPM que é “Imported”.

Após isso, executa o inventário completo e o DPM recuperará as informações da fita, porem nas experiências que já tive não será possivel fazer o restore já que a referencia no banco de dados que o console utilizou foi o OMID e não o barcode na ocasião. O ideal neste caso é marcar as fitas como “free” e re-executar os backups.

Fonte: http://technet.microsoft.com/en-us/library/bb808923.aspx

SINTOMA

Ao acrescentar um novo nó em um cluster já existente enfrentei um problema no HA (High Avaliability) quando ao mover o storage ocorreu o erro “This node is not a possible owner for this resource”.

CAUSA

Em geral este erro não acontece, pois ao se acrescentar um novo nó ao cluster este já adiciona o novo host como “Possible Owner”, porem neste caso em especial o problema foi a configuração do iSCSI que estava incorreta e o novo host não conseguia acessar uma das unidades do CSV, ocasionando “Redirect Access”.

Após resolver o problema dos endereçamentos do iSCSI os discos ficaram visiveis, porem ele não era migrado para o novo host e acusa o erro indicando que o novo host não era um dos possiveis owners.

No caso de uma VM ou o Quorum basta clicar com o botão direito para acessar a lista de Possible Owners, mas isso não existe em unidades de storage.

Solução

Utilizando o PowerShell Modules execute o cmdlet abaixo e veja que uma das unidades do storage não tem o novo servidor na lista de nós:

Get-ClusterSharedVolume | Get-ClusterOwnerNode

ClusterObject                                            OwnerNodes
-------------                                               ----------
Unidade_G                                               {ServerA}
Unidade_H                                              {ServerA, ServerB}

Na sequencia utilize o comlet abaixo para definir os Owners da unidade que está incorreta:

Set-ClusterOwnerNode –Owners ServerA,ServerB -Resource "Unidade_G"

Por fim, execute o comando inicial novamente e veja que agora os Owners estão corretos:

Get-ClusterSharedVolume | Get-ClusterOwnerNode

ClusterObject                                            OwnerNodes
-------------                                               ----------
Unidade_G                                               {ServerA, ServerB}
Unidade_H                                               {ServerA, ServerB}

Nota

Antes de conseguir resolver o problema tentava utilizar o cmdlet Get-ClusterResource  | Get-ClusterOwnerNode porém unidades CSV não listados, com excessão do Quorum.