Arquivos tempdb do SQL Server 2005 movidos para a unidade (SSD) inválida. Como validar a unidade ou como mover os arquivos de volta?

Question

SQL 2005 32bit Developer edition, todos os service packs recentes

Windows Server 2003 Standard 64x, todas as atualizações recentes

Unidade de Fusão IO

Instalamos uma nova placa SSD de 80 GB em nosso servidor de desenvolvimento, executamos ALTER TABLE em tempdb (tamanho inicial de 10 GB) para mover esses arquivos para a nova unidade, paramos o SQL Server e tentamos reiniciá-lo ... mas agora SQL não será iniciado, com "Ocorreu um erro específico do serviço: 1814". Sys.Messages tem 1814 como "Não foi possível criar tempdb. Você pode não ter espaço em disco suficiente disponível. Libere espaço em disco adicional excluindo outros arquivos na unidade tempdb e reinicie o SQL Server. Verifique se há erros adicionais no log de eventos que podem indicar porque os arquivos tempdb não puderam ser inicializados. " O log de eventos do aplicativo tem "FCB :: Open: Ocorreu um erro no sistema operacional 5 (acesso negado.) Durante a criação ou abertura do arquivo 'F: \ TempDB'. Diagnostique e corrija o erro do sistema operacional e tente novamente a operação." O serviço SQL está configurado para ser executado como uma conta de domínio e essa conta é o administrador local na caixa.

Meu palpite é que algum stealth-bit precisa ser configurado em algum lugar que "habilite" a nova unidade a ser usada pelo SQL Server. Alguma idéia do que isso poderia ser?

O que eu realmente gostaria de fazer é dizer ao SQL para não construir os arquivos tempdb nessa unidade ... mas para fazer isso você precisa emitir um ALTER DATABASE para mover os arquivos, mas não podemos iniciar o serviço para emitir esse comando. Como você move arquivos tempdb para uma instância do SQL Server 2005 (nomeada) sem realmente executar a instância? (É SQL 2005, então eu não posso simplesmente hackear as tabelas no banco de dados mestre como eu poderia em 2000 ou 7.0).

E não, nós não temos backups de nossos bancos de dados do sistema. Ou isso teria ajudado aqui?

    

Answer 1

LEIA. A mensagem de erro.

Diz:

Application event log has "FCB::Open: Operating system error 5(Access is denied.) occurred while creating or opening file 'F:\TempDB'.

Você pode tentar pedir a alguém para lhe explicar "Acesso negado";)

My guess is that some stealth-bit needs to be configured somewhere that "enables" the new drive for use by SQL Server. Any ideas what this might be?

Sim, eles são chamados de segurança. O NTFS possui segurança bastante detalhada nas unidades. O usuário que está executando o SQL Server (depende de como você o instalou) não tem as permissões necessárias na unidade para criar os arquivos. Nada "especial" sobre o SQL Server - esse é um problema com permissões simples, primitivas e normais do sistema de arquivos.

The SQL service is configured to run as a domain account, and that account is local admin on the box

Bem, além de ser o administrador local (irrelevante, STRONGLY não é recomendado - seriamente) - verifique se essa conta pode realmente criar o arquivo em questão (ou um nome similar). Se não (permissões do sistema de arquivos), esse é o problema. Minha aposta.

Dito isso, eu geralmente questionaria o uso de um SSD para um arquivo tempdb. Seriamente desperdiçar dinheiro em 99% dos casos.

    

Answer 2

Parece que o problema ocorreu quando o administrador (não eu, honestamente!) entrou nos caminhos errados para os arquivos, embora nunca saibamos com certeza. Ele conseguiu consertá-lo de alguma forma, iniciando o SQL com os switches -c e -f e alterando novamente os arquivos para locais apropriados.

(Desculpe por ocupar o seu tempo. Ficamos recorrentes se problemas infrequentes da mesma fonte por aqui. Você acha que até agora eu percebi que os problemas básicos não são básicos para algumas pessoas.)

    

Answer 3

parece que você fez mangueira do seu sistema dbs. SEMPRE bancos de dados do sistema de backup ... eles podem ser úteis mais tarde, em momentos como esse.

link

tente fazer o sql rodar novamente - então faça um anexo com o banco de dados.

então, é claro, certifique-se de que o sistema operacional reconheça a nova unidade e que ela esteja toda formatada e pronta para uso - e certifique-se de que a ID em que você está executando sql possa acessar essa unidade.

espero que ajude, boa sorte!

    

Answer 4

Em relação aos backups dos bancos de dados do sistema: master, model, msdb yes. O tempdb é reconstruído toda vez que o serviço do mecanismo de banco de dados é reiniciado, portanto, pulo o tempdb.

    

Answer 5

Isto pode ser (é um grande erro) relacionado a um bug conhecido que quando você move tempdb usando ALTER DATABASE, o SQL Server procura pelo espaço livre especificado (no seu caso 10GB) na unidade original e não na sua nova Unidade SSD. Portanto, se não houver 10 GB na unidade original, ele falhará. O que você deve fazer é mover o banco de dados primeiro para sua nova unidade SSD usando tamanho pequeno (como 1MB) e redimensioná-lo novamente para o tamanho desejado (10GB)

Brent Ozar explicou aqui melhor.

    

Answer 6

não tem certeza se você já resolveu isso, mas aqui vai ... parece que o SQL está procurando pela pasta "F: \ TempDB" para criar os arquivos de dados quando ele é reiniciado. F: \ dirige o novo drive Fusion-IO? Se sim, você já criou uma pasta "TEMPDB" na unidade com as permissões apropriadas para que o SQL possa acessá-la?

O SQL tentará acessar diretamente a pasta e não criará a pasta caso ela não exista ... aí reside, provavelmente, o seu problema! Espero que isso ajude.

Cumprimentos Chirag