MSSQLSERVER_17207

Aplica-se a: SQL Server

Details

Explanation

O SQL Server não conseguiu abrir o ficheiro especificado devido ao erro do sistema operativo especificado.

Pode ver o erro 17207 no Evento de Aplicação Windows ou no registo de erros do SQL Server quando o SQL Server não consegue abrir uma base de dados e/ou ficheiros de registo de transações. Aqui está um exemplo de como pode ser o erro.

Error: 17207, Severity: 16, State: 1.
FileMgr::StartSecondaryDataFiles: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'F:\MSSQL\DATA\MyDB_FG1_1.ndf'. Diagnose and correct the operating system error, and retry the operation.

Pode ver estes erros durante o processo de arranque da instância do SQL Server ou em qualquer operação de base de dados que tente iniciar a base de dados (por exemplo, ALTER DATABASE). Em alguns cenários, pode ver tanto os erros 17207 como 17204 e, noutras ocasiões, pode apenas ver um deles.

Se uma base de dados de utilizador encontrar estes erros, essa base de dados ficará no estado RECOVERY_PENDING e as aplicações não poderão aceder à base de dados. Se uma base de dados do sistema encontrar estes erros, a instância do SQL Server não arrancará e não poderá ligar-se a esta instância do SQL Server. Isto pode também resultar em um recurso de cluster de failover do SQL Server ficar offline.

Se o problema estiver relacionado com o seu grupo de ficheiros SQL Server FileStream, então notará que apenas o caminho completo da pasta está listado em vez de um nome de ficheiro. Vejamos um exemplo.

Error: 17207, Severity: 16, State: 1.
STREAMFCB::Startup: Operating system error 2(The system cannot find the file specified.) occurred while creating or opening file 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\bpa_files_test_fs_1\bpa_files_test_fs_1'. Diagnose and correct the operating system error, and retry the operation.

Motivo

Antes de qualquer base de dados SQL Server poder ser utilizada, a base de dados precisa de ser iniciada. O processo de arranque da base de dados envolve inicializar várias estruturas de dados que representam a base de dados e os ficheiros da base de dados, abrir todos os ficheiros que pertencem à base de dados e, finalmente, executar a recuperação na base de dados. O SQL Server utiliza a função CreateFile da API Windows para abrir os ficheiros que pertencem a uma base de dados.

As mensagens 17207 (e 17204) indicam que foi encontrado um erro enquanto o SQL Server tentava abrir os ficheiros da base de dados durante o processo de arranque.

Estas mensagens de erro contêm a seguinte informação:

1. Nome da função SQL Server que está a tentar abrir o ficheiro. O nome da função que normalmente observa nestas mensagens de erro é um dos seguintes:

   • FCB::Open - o ficheiro encontrou um erro quando o SQL Server tenta abri-lo
   • FileMgr::StartPrimaryDataFiles - um ficheiro de dados primário ou um ficheiro pertencente ao grupo de ficheiros primário
   • FileMgr::StartSecondaryDataFiles - um ficheiro pertencente a um grupo secundário de ficheiros
   • FileMgr::StartLogFiles - um ficheiro de registo de transações
   • STREAMFCB::Startup - Contentor SQL FileStream
   • FCB::RemoverFluxosAlternativos

2. A informação de estado distingue múltiplas localizações dentro de uma função que pode gerar esta mensagem de erro.

3. O caminho físico completo para o ficheiro.

4. O ID do ficheiro correspondente ao ficheiro.

5. O código de erro do sistema operativo e a descrição do erro. Em alguns casos, verá apenas o código de erro.

A informação de erro do sistema operativo impressa nestas mensagens de erro é a causa raiz que leva ao erro 17204. As causas comuns destas mensagens de erro são um problema de permissões ou um caminho incorreto para o ficheiro.

Ação do usuário

1. Resolver o erro 17207 envolve compreender o código de erro associado ao sistema operativo e diagnosticar esse erro. Uma vez resolvida a condição de erro do sistema operativo, pode tentar reiniciar a base de dados (usando ALTER DATABASE SET ONLINE, por exemplo) ou a instância do SQL Server para colocar a base de dados afetada online. Em alguns casos, pode não conseguir resolver o erro do sistema operativo, pelo que terá de tomar ações corretivas específicas. Vamos discutir estas ações nesta secção.

2. Se a mensagem de erro 17207 contiver apenas um código de erro e não uma descrição de erro, pode tentar resolver o código de erro usando o comando de um shell do sistema operativo: net helpmsg <código> de erro . Se estiver a receber um código de estado de 8 dígitos como código de erro, então pode consultar as fontes de informação como Como converter um HRESULT num código de erro Win32? para decodificar o que estes códigos de estado em erros do sistema operativo.

3. Se você estiver recebendo o erro do Access is Denied sistema operacional = 5, considere estes métodos:

   • Verifique as permissões definidas no ficheiro olhando para as propriedades do ficheiro no Explorador do Windows. O SQL Server utiliza grupos do Windows para fornecer controlo de acesso aos vários recursos de ficheiros. Certifique-se de que o grupo apropriado (com nomes como SQLServerMSSQLUser$ComputerName$MSSQLSERVER ou SQLServerMSSQLUser$ComputerName$InstanceName) tem as permissões necessárias no ficheiro da base de dados mencionado na mensagem de erro. Consulte Configurar permissões do sistema de arquivos para acesso ao mecanismo de banco de dados para obter mais detalhes. Verifique se o grupo do Windows realmente inclui a conta de inicialização do serviço SQL Server ou o SID do serviço.

   • Examine a conta de usuário sob a qual o serviço do SQL Server está sendo executado no momento. Pode utilizar o Gestor de Tarefas do Windows para obter estas informações. Procure o valor "Nome de usuário" para o executável "sqlservr.exe". Além disso, se mudou recentemente a conta do serviço SQL Server, saiba que a forma suportada de fazer esta operação é usar a utilidade Gestor de Configuração do SQL Server. Mais informações sobre isto estão disponíveis no Gestor de Configuração do SQL Server.

   • Dependendo do tipo de operação (abertura de bancos de dados durante a inicialização do servidor, anexação de um banco de dados, restauração de banco de dados e assim por diante), a conta usada para representação e acesso ao arquivo de banco de dados pode variar. Analise o tópico Protegendo dados e arquivos de log para entender qual operação define qual permissão e para quais contas. Use uma ferramenta como o Windows SysInternals Process Monitor para perceber se o acesso ao ficheiro está a acontecer no contexto de segurança da conta de arranque do serviço de instância do SQL Server (ou SID do Serviço) ou de uma conta usurpada.

     Se o SQL Server estiver a imitar as credenciais de utilizador do login que executa a ALTER DATABASE operação ouCREATE DATABASE, notará a seguinte informação na ferramenta Process Monitor (um exemplo).

     Date & Time:      3/27/2010 8:26:08 PM
     Event Class:        File System
     Operation:          CreateFile
     Result:                ACCESS DENIED
     Path:                  C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\attach_test.mdf
     TID:                   4288
     Duration:             0.0000366
     Desired Access:Generic Read/Write
     Disposition:        Open
     Options:            Synchronous IO Non-Alert, Non-Directory File, Open No Recall
     Attributes:          N
     ShareMode:       Read
     AllocationSize:   n/a
     Impersonating: DomainName\UserName
     

4. Se estiver a receber The system cannot find the file specified erro do sistema operativo = 3:

   • Revise o percurso completo da mensagem de erro.
   • Certifique-se de que a unidade de disco e o caminho da pasta são visíveis e acessíveis a partir do Explorador do Windows.
   • Consulte o registo de eventos do Windows para saber se existem problemas com esta unidade de disco.
   • Se o caminho estiver incorreto e se essa base de dados já existir no sistema, pode alterar os caminhos dos ficheiros da base de dados usando os métodos explicados no artigo Move Database Files . Pode ter de usar este procedimento, especialmente para ficheiros de base de dados do sistema que encontram 17204 ou 17207 e está a lidar com um cenário de recuperação de desastres onde os discos especificados não estão disponíveis. Este tópico também explica como pode identificar a localização atual das várias bases de dados do sistema [master, model, tempdb, msdb e mssqlsystemresource].
   • Se vir este erro porque os ficheiros da base de dados estão em falta, tem de restaurar a base de dados a partir de uma cópia de segurança válida:
     • Se o ficheiro da base de dados associado ao erro pertencer a um grupo secundário, então pode, opcionalmente, marcar esse grupo offline, ativar a base de dados e depois realizar uma restauração desse grupo sozinho. Para mais informações, consulte a secção OFFLINE do tópico ALTER DATABASE Opções de Ficheiros e Grupos de Ficheiros (Transact-SQL).
     • Se o ficheiro que gerou o erro for um ficheiro de registo de transações, reveja a informação nas secções "FOR ATTACH" e "FOR ATTACH_REBUILD_LOG" do tópico CREATE DATABASE (Transact-SQL) para perceber como pode recriar os ficheiros de registo de transações em falta.
   • Certifique-se de que qualquer localização de disco ou rede [como o disco iSCSI] está disponível antes de o SQL Server tentar aceder aos ficheiros da base de dados nesses locais. Se necessário, crie as dependências necessárias no Administrador de Cluster ou no Gestor de Controlo de Serviços.

5. Se estiveres a receber o The process cannot access the file because it is being used by another process erro do sistema operativo = 32:

   • Use uma ferramenta como o Process Explorer ou Handle from Windows Sysinternals para descobrir se outro processo ou serviço adquiriu bloqueio exclusivo neste ficheiro de base de dados.
   • Impedir esse processo de aceder aos ficheiros da base de dados do SQL Server. Exemplos comuns incluem programas antivírus (ver orientação para exclusões de ficheiros no artigo seguinte da KB).
   • Num ambiente de cluster, certifique-se de que o processo sqlservr.exe do nó proprietário anterior libertou os handles para os ficheiros da base de dados. Normalmente isto não acontece, mas configurações incorretas do cluster ou dos caminhos de I/O podem levar a esses problemas.