SQL Server 2005，有个ndf文件居然有117GB，怎么搞定它？

[extend]

如题，我是真没办法了，ndf是从文件，但是不知道里面都写些啥，也不敢删了。

有任何办法能压缩下它吗？

[extend]

楼上的方法不解决问题

[obuntu]

先
dbcc updateusage 看看，也可能是内部大小计算错误。

[fanzhouqi]

可以收缩数据文件的

[extend]

use DBname


DBCC SHRINKFILE
( 5
, 200
)

执行过程中报这个错:
DBCC SHRINKFILE: File ID 5 of database ID 7 was skipped because the file size was changed in the middle of shrink operation.
Msg 0, Level 11, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.

咋办呢？

[永生天地]

我对我的master执行，好用。我也不是很懂

sp_spaceused 
/*
database_name         database_size      unallocated space  
---------------------- ------------------ ------------------ 
master                263.31 MB          257.67 MB

reserved           data               index_size         unused             
------------------ ------------------ ------------------ ------------------ 
5008 KB            2648 KB            1952 KB            408 KB

*/


DBCC SHRINKFILE
    (  1    ,  10    )

sp_spaceused 
/*
database_name         database_size      unallocated space  
---------------------- ------------------ ------------------ 
master                10.75 MB           5.06 MB

reserved           data               index_size         unused             
------------------ ------------------ ------------------ ------------------ 
5056 KB            2640 KB            1952 KB            464 KB

*/

[Q315054403]

看它是哪个文件组，再看有哪些对象在这个文件组中，分别占多少空间，再作处理。。。直接收缩也行

[xyj052]

直接用维护计划，做收缩可以吗？

[extend]

首先，这不是日志文件过大的问题，这是ndf文件过大的问题。

其次，收缩了，但不解决问题。

dbcc updateusage (DBName)
use DBName
DBCC SHRINKFILE
( 5
, 200
)

结果如下：

Dbid FileID Currentsize MinimumSize Usedpages EstimatedPages
7 5 15279528 128 15279288 15279288

可见，做了收缩后，大小没变化。

[obuntu]

你确定你们没有这么多的数据？

[extend]

LS，嗯，基本可以确定根本没那么多数据。

[claro]

[Quote=引用 17 楼 extend 的回复:]

首先，这不是日志文件过大的问题，这是ndf文件过大的问题。

其次，收缩了，但不解决问题。

dbcc updateusage (DBName)
use DBName
DBCC SHRINKFILE
( 5
, 200
)

结果如下：

Dbid FileID Currentsize MinimumSize Usedpages E……
[/Quote]
哦，是数据文件。
这是个经典的问题。

[昵称被占用了]

要查一下这个文件所属文件组是哪个，你的库什么数据放在这个文件组。
不能凭印象确定是不是应该这么大，既然收缩不了说明确实方的是数据

或者你先如下查下：

select top 100 
name as indexname
,object_name(id) as tablename
,used
,rows
,indid
from sysindexes
order by used desc

看看到底哪里占用空间大，是索引还是数据(不会分析的话贴出结果帮你分析)

[claro]

比方说官方会给你这样的解释：
1、数据文件里面虽然有很多空的页面，可能因为你已经del了，但绝不是truncate处理的，所以这些页面实际分散在各个区里，这样使得整个文件组没有很多空的区。
而SHRINKFILE是针对区进行处理，它把使用过的区进行移动，比如前移，把没在使用的区从文件中移除。换言之，如果这个命令是做页的收缩，你的问题肯定可以解决，但结果不是。
所以你需要检查是否一个区中只有很少的页面存在。如果存在索引的话，把索引redo一次（这里不是指碎片整理），再试试。

[claro]

2、可以利用extentinfo查看区分配的相关信息。
如果不急的话，稍候将解释如何利用extentinfo进行区信息分解。
也可以谷歌查询一下，这篇文档对你有用。

[extend]

Haiwer：
这段语句中的tablename是什么？我这是一个数据文件大，应该查哪张表？
select top 100
name as indexname
,object_name(id) as tablename
,used
,rows
,indid
from sysindexes
order by used desc

[extend]

做过收缩了，但是那个.ndf文件一点不见小，有啥办法能抛开这个文件，再重建这个文件？就是让数据库用一个全新的.ndf文件继续运行，100+GB那个文件是删还是挪个地方就好办了。

[昵称被占用了]

收缩文件，看看其显示的可用空间是不是很大，如果很大，指定收缩后大小来收缩，否则，需要调查下这个文件到底存放了什么，是不是真正的数据或者索引

[claro]

一、要解决日志如此之大的问题：
前提：数据库存在有效备份且合理的备份机制。
方式：将数据库的恢复模式设置为simple。
作用：每次数据库自动checkpoint时，会截断日志。

二、为何产生如何庞大日志文件：（用DBCC log的方式）
1、执行sp_helpdb 'BBS'或者select database_id from sys.databases where name='BBS'得到数据库ID
2、再执行DBCC log (数据库ID,3)，查看显示结果集。--这里的数据库ID不需要添加引号。

[claro]

抽时间写关于数据库日志文件的相关文档给LZ，请关注RSS。

[liyaohui13098452233]

[Quote=引用 3 楼 liyaohui13098452233 的回复:]
收缩这个文件
[/Quote]


这个不行吗？