otro - "Primary Filegroup is Full" en SQL Server 2008 Standard sin motivo aparente

no se puede conectar a local sql server 2008

Question

Nuestra base de datos se encuentra actualmente en 64 Gb y una de nuestras aplicaciones comenzó a fallar con el siguiente error:

System.Data.SqlClient.SqlException : no se pudo asignar espacio para el objeto ''cnv.LoggedUnpreparedSpos''.''PK_LoggedUnpreparedSpos'' en la base de datos ''travelgateway'' porque el grupo de archivos ''PRIMARY'' está lleno. Cree espacio en disco eliminando archivos innecesarios, soltando objetos en el grupo de archivos, agregando archivos adicionales al grupo de archivos o estableciendo el crecimiento automático para los archivos existentes en el grupo de archivos.

Comprobé todo dos veces: todos los archivos de un solo grupo de archivos pueden crecer automáticamente con incrementos razonables (100 Mb para un archivo de datos, 10% para un archivo de registro), más de 100 Gb de espacio libre disponible para la base de datos, tempdb está configurado para crecer de forma automática con un montón de espacio libre en disco duro en su disco.

Para resolver un problema, agregué un segundo archivo al grupo de archivos y el error desapareció. Pero me siento incómodo con toda esta situación.

¿Dónde está el problema aquí, muchachos?

Answer 1

Anton,

Como práctica recomendada, no se deben crear objetos de usuario en el grupo de archivos primario. Cuando tenga ancho de banda, cree un nuevo grupo de archivos y mueva los objetos del usuario y deje los objetos del sistema en primario.

Las siguientes consultas lo ayudarán a identificar el espacio utilizado en cada archivo y las tablas principales que tienen el mayor número de filas y si hay montones. Es un buen punto de partida para investigar este problema.

SELECT  
ds.name as filegroupname
, df.name AS ''FileName'' 
, physical_name AS ''PhysicalName''
, size/128 AS ''TotalSizeinMB''
, size/128.0 - CAST(FILEPROPERTY(df.name, ''SpaceUsed'') AS int)/128.0 AS ''AvailableSpaceInMB'' 
, CAST(FILEPROPERTY(df.name, ''SpaceUsed'') AS int)/128.0 AS ''ActualSpaceUsedInMB''
, (CAST(FILEPROPERTY(df.name, ''SpaceUsed'') AS int)/128.0)/(size/128)*100. as ''%SpaceUsed''
FROM sys.database_files df LEFT OUTER JOIN sys.data_spaces ds  
    ON df.data_space_id = ds.data_space_id;

EXEC xp_fixeddrives
select  t.name as TableName,  
    i.name as IndexName, 
    p.rows as Rows
from sys.filegroups fg (nolock) join sys.database_files df (nolock)
    on fg.data_space_id = df.data_space_id join sys.indexes i (nolock) 
    on df.data_space_id = i.data_space_id join sys.tables t (nolock)
    on i.object_id = t.object_id join sys.partitions p (nolock)
on t.object_id = p.object_id and i.index_id = p.index_id  
where fg.name = ''PRIMARY'' and t.type = ''U''  
order by rows desc
select  t.name as TableName,  
    i.name as IndexName, 
    p.rows as Rows
from sys.filegroups fg (nolock) join sys.database_files df (nolock)
    on fg.data_space_id = df.data_space_id join sys.indexes i (nolock) 
    on df.data_space_id = i.data_space_id join sys.tables t (nolock)
    on i.object_id = t.object_id join sys.partitions p (nolock)
on t.object_id = p.object_id and i.index_id = p.index_id  
where fg.name = ''PRIMARY'' and t.type = ''U'' and i.index_id = 0 
order by rows desc

Answer 2

Descubrí que esto sucede porque: http://support.microsoft.com/kb/913399

SQL Server solo publica todas las páginas que utiliza una tabla de almacenamiento dinámico cuando se cumplen las siguientes condiciones: se produce una eliminación en esta tabla. Se está reteniendo un nivel de tabla. Nota Una tabla de acumulación es cualquier tabla que no está asociada con un índice agrupado.

Si las páginas no se desasignan, otros objetos en la base de datos no pueden reutilizar las páginas.

Sin embargo, cuando habilita un nivel de aislamiento basado en el control de versiones de una base de datos de SQL Server 2005, las páginas no se pueden liberar, incluso si se mantiene un bloqueo de nivel de tabla.

La solución de Microsoft: http://support.microsoft.com/kb/913399

Para evitar este problema, utilice uno de los métodos siguientes: Incluya una sugerencia de TABLOCK en la instrucción DELETE si un nivel de aislamiento basado en versiones de fila no está habilitado. Por ejemplo, use una declaración que sea similar a la siguiente:

ELIMINAR DE TableName WITH (TABLOCK)

La nota representa el nombre de la tabla. Utilice la sentencia TRUNCATE TABLE si desea eliminar todos los registros en la tabla. Por ejemplo, use una declaración que sea similar a la siguiente:

TRUNCATE TABLE TableName

Cree un índice agrupado en una columna de la tabla. Para obtener más información acerca de cómo crear un índice agrupado en una tabla, consulte el tema "Creación de un índice agrupado" en SQL.

Notarás en la parte inferior del enlace que NO se observa que se aplica a SQL Server 2008, pero creo que sí

Answer 3

Haga una cosa, acceda a las propiedades de los archivos de selección de la base de datos y aumente el tamaño inicial de la base de datos y configure el grupo de archivos principal como autoincrementado. Reinicie el servidor sql.

Podrá usar la base de datos como antes.

Answer 4

Me encontré con el mismo problema. La razón fue que el archivo de memoria virtual "pagefile.sys" estaba ubicado en la misma unidad que nuestros archivos de datos para nuestras bases de datos (D: unidad). Se había duplicado en tamaño y había llenado el disco, pero Windows no lo estaba recogiendo, es decir, parecía que teníamos 80 GB libres cuando en realidad no lo hacíamos.

Reiniciar el servidor SQL no ayudaba, tal vez desfragmentar le daría tiempo al sistema operativo para liberar el archivo de paginación, pero simplemente reiniciamos el servidor y voila, el archivo de paginación se había encogido y todo funcionaba bien.

Lo que es interesante es que durante los 30 min que estábamos investigando, Windows no calculó el tamaño del archivo pagefile.sys en absoluto (80 gb). Después de reiniciar Windows encontró el archivo de paginación e incluyó su tamaño en el uso total del disco (ahora 40 gb, que aún es demasiado grande).

Answer 5

OK, funcionó. Resulta que un volumen NTFS donde estaban ubicados los archivos DB se fragmentó mucho . Dejó SQL Server, desfragmentó todo y todo quedó bien desde entonces.

Answer 6

Por favor, controle el tipo de crecimiento de archivos de la base de datos, si está restringida, hágalo sin restricciones.

Answer 7

Se encontró con el mismo problema y al principio la desfragmentación pareció funcionar. Pero fue por poco tiempo. Apaga el servidor que el cliente estaba usando, estaba ejecutando la Express version y tiene un límite de licencia de aproximadamente 10 10gb .

Entonces, aunque el tamaño se estableció en "ilimitado", no fue así.

Answer 8

También encontré el mismo problema, donde el tamaño de la base de datos inicial se establece en 4Gb y el crecimiento automático se establece en 1Mb. La unidad TrueCrypt cifrada virtual en la que se encontraba el databse parecía tener mucho espacio.

Cambié un par de cosas (las anteriores):

• Convertí el servicio de Windows para Sql Server Express de automático a manual , por lo que solo se está ejecutando el servidor Sql ''normal''. (Aunque estoy ejecutando Sql Server 2008 R2, que debería permitir 10 GB).
• Cambié la autocreencia de 1 MB a 10%
• Cambié el tamaño de incremento del crecimiento automático de 10% a 1000 MB
• Desfragmentamos el disco
• Reduje la base de datos:
  • manualmente DBCC SHRINKDATABASE(''...'')
  • automáticamente haga clic derecho en la base de datos | "propiedades" | "Auto encogimiento" | "Truncar el registro en el punto de verificación")

Todo con poco provecho (pude insertar algunos registros más, pero pronto encontré el mismo problema). El archivo de paginación mencionado por Tobbi me hizo probar un disco virtual más grande. (Aunque mi disco no debería contener ningún archivo de sistema de este tipo, ya que funciono sin que se monte mucho).

• Hice un nuevo disco virtual más grande con TrueCrypt

Al hacer esto, me encontré con una pregunta TrueCrypt, si voy a almacenar archivos de más de 4 gb ( como se muestra en esta pregunta SuperUser ).

• Le dije a TrueCrypt que almacenaría archivos de más de 4 GB

Después de estos dos últimos, estaba bien, y supongo que este último hizo el truco. Creo que TrueCrypt elige un sistema de archivos exfat ( como se describe aquí ), que limita todos los archivos a 4GB. (Entonces, probablemente, no necesité agrandar el disco, pero lo hice de todos modos).

Este es probablemente un caso fronterizo muy raro, pero tal vez sea de ayuda para alguien.

Answer 9

nuestro problema era que el disco duro se había reducido a cero espacio disponible.