重建索引

Question

1.sqlserver2005有一个数据库abc，其中有一个表叫tblView，如何用sql语句重建tblView的索引
2.如何用sql压缩abc数据库
3.如何清除abc的数据库日志

Answer 1

1、打开SSMS→管理→维护计划→新建维护计划，名字随便→在左边的工具栏里面，把重建索引拉进去，双击→设置数据库→点击【查看T-SQL】就自动生成脚本了。
2、只有2008以后才有压缩，你应该是问【收缩】吧：
USE [AdventureWorks]
 GO
 DBCC SHRINKDATABASE(N'AdventureWorks' )
 GO
 3、定期做日志备份实际上已经在清除日志了，做了日志备份之后，日志中的数据就是【未提交】的事务，没必要清除。做了日志备份之后收缩日志文件就可以了：
USE [AdventureWorks]
 GO
 DBCC SHRINKFILE (N'AdventureWorks_Log' , 0, TRUNCATEONLY)
 GO
 

Answer 2

--1、create index 加上 with(drop_existing=on)选项
--例
CREATE NONCLUSTERED INDEX IX_WorkOrder_ProductID
ON Production.WorkOrder(ProductID)
WITH (DROP_EXISTING = ON);--2、dbcc shrinkfile 和 dbcc shrinkdatabase--3
--<1>.清空日志 
DUMP     TRANSACTION     库名     WITH     NO_LOG         
--<2>.截断事务日志： 
BACKUP   LOG   库名   WITH   NO_LOG

Answer 3

第一步看错了，以为是全库重建，单表重建可以这样：
ALTER INDEX [PK_AWBuildVersion_SystemInformationID] ON [dbo].[AWBuildVersion] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, ONLINE = OFF, SORT_IN_TEMPDB = OFF )
 GO表名、索引名自己替换

Answer 4

use abc
goALTER INDEX all on tblView
REBUILD;--2，3  
DBCC SHRINKDATABASE 
DBCC SHRINKFILE
http://msdn.microsoft.com/zh-cn/library/ms190488.aspx
http://msdn.microsoft.com/zh-cn/library/ms189493

Answer 5

--1、
(1)
DBCC DBREINDEX
    (    [ 'database.owner.table_name'    
            [ , index_name
                [ , fillfactor ]
            ] 
        ] 
    )    [ WITH NO_INFOMSGS ]
(2)
alter index indexname rebuild--2
1.清空日志
　 DUMP TRANSACTION 库名 WITH NO_LOG  
2.截断事务日志：
　 BACKUP LOG 数据库名 WITH NO_LOG/*3.收缩数据库文件(如果不压缩,数据库的文件不会减小
　 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件
　   --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
　   --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了*/
　 也可以用SQL语句来完成
　 --收缩数据库
　 DBCC SHRINKDATABASE(客户资料)
　 --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles
　 DBCC SHRINKFILE(1)
4.为了最大化的缩小日志文件(如果是sql 7.0,这步只能在查询分析器中进行)
　 a.分离数据库:
　   企业管理器--服务器--数据库--右键--分离数据库
　 b.在我的电脑中删除LOG文件
　 c.附加数据库:
　   企业管理器--服务器--数据库--右键--附加数据库
　 此法将生成新的LOG，大小只有500多K
　 或用代码：
　 下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。
　 a.分离
　 E X E C sp_detach_db @dbname = 'pubs'
　 b.删除日志文件
　 c.再附加
　 E X E C sp_attach_single_file_db @dbname = 'pubs',
　   @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf'
5.为了以后能自动收缩,做如下设置:
　 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"
　 --SQL语句设置方式:
　 E X E C sp_dboption '数据库名', 'autoshrink', 'TRUE'
6.如果想以后不让它日志增长得太大
　 企业管理器--服务器--右键数据库--属性--事务日志
　   --将文件增长限制为xM(x是你允许的最大数据文件大小)
　 --SQL语句的设置方式:
　 alter database 数据库名 modify file(name=逻辑文件名,maxsize=20)
特别注意：
　 请按步骤进行,未进行前面的步骤,请不要做后面的步骤
　 否则可能损坏你的数据库.
　 一般不建议做第4,6两步
　 第4步不安全,有可能损坏数据库或丢失数据
　 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复.另外提供一种更简单的方法，本人屡试不爽，建议大家使用。
更简单的方法：
   1。右建数据库属性窗口--故障还原模型--设为简单
   2。右建数据库所有任务--收缩数据库
   3。右建数据库属性窗口--故障还原模型--设为大容量日志记录--3、清空日志 
DUMP     TRANSACTION     @DataBaseName     WITH     NO_LOG       
DBCC     SHRINKFILE(     @LogoFileName,@NewSize) --假设test2为数据库名称   日志已经很大的时候用   
方法一此方法适用于7.0和2000。   1、在查询分析器中执行：   exec   sp_detach_db   'DB_Name ', 'true '   
2、在我的电脑中将日志的物理文件xxx_Log.LDF改名。   
3、在查询分析器中执行：  
 exec   sp_attach_single_file_db   'DB_Name ', 'C:\Program   Files\Microsoft   SQL   Server\MSSQL\Data\DB_Name.MDF '   
4、如果上一步成功，将步骤2中改名后的文件删除。如果上一步不成功，改回原来的文件名，用sp_attach_db将数据库附加到服务器，然后用方法二。   --方法二   
--6.X中   
DUMP   TRANSACTION   test2   with   NO_LOG   DUMP   TRANSACTION   test2   with   TRUNCATE_ONLY   
--将上面的语句多次执行，直到日志缩小。7.0和2000中  
 backup   log   test2   with   NO_LOG   backup   log   test2   with   TRUNCATE_ONLY   DBCC   SHRINKDATABASE(test2) 
 -- 将上面的语句多次执行，直到日志文件缩小。上面的方法治标不治本，标本兼治要用下面的方法。   方法三：   
--6.X和7.0中改为日志处于截断模式，2000中恢复模型改为简单恢复  
 exec   sp_dboption   'test2 ', 'trunc.   log   on   chkpt. ', 'on '   
--7.0和2000中设为自动收缩,6.x中不用执行。  
 exec   sp_dboption   'test2 ', 'autoshrink ', 'on '   通常用于测试环境。   方法四:   --7.0中改为日志不处于截断模式，2000中恢复模型改为完全恢复 
exec   sp_dboption   'test2 ', 'trunc.   log   on   chkpt. ', 'off '   --7.0和2000中设为自动收缩,6.x中不用执行。   
exec   sp_dboption   'test2 ', 'autoshrink ', 'on '   建立作业,每半个小时一次日志备份,每天一次完全数据库备份。   7.0和2000中：在Log收缩到正常大小后，将autoshrink选项设置为off。通常用于真实环境。   在产品化系统中将autoshrink选项设置为开启状态并非明智之举（除非您真的需要这样做），这是因为，当您的系统正在忙于完成其它任务时，autoshrink选项可能会同时启动，从而降低系统运行速度。然而，对于那些数据库管理员无暇估计并且数据库尺寸有可能在您毫无察觉的情况下超出控制范围的桌面或远程系统来说，开启这一选项却是一种非常有效的措施。   收缩事务日志   在下列情况下，日志文件的物理大小将减少：   *执行   DBCC   SHRINKDATABASE   语句时。   
*执行引用日志文件的   DBCC   SHRINKFILE   语句时。   
*自动收缩操作发生时。   日志收缩操作依赖于最初的日志截断操作。日志截断操作不减小物理日志文件的大小，但减小逻辑日志的大小，并将没有容纳逻辑日志任何部分的虚拟日志标记为不活动。日志收缩操作会删除足够多的不活动虚拟日志，将日志文件减小到要求的大小。   按下面任一方式控制事务日志的大小：   
*在维护日志备份序列时，调度BACKUP   LOG语句按间隔发生，以使事务日志不致增长到超过预期的大小。   
*当不维护日志备份序列时，指定简单恢复模式。   详情请参考   MS   SQL   Server   2000   联机丛书：   目录-->   SQL   Server构架--> 数据库构架--> 物理数据库构架--> 事务日志构架--> 收缩事务日志   目录-->   SQL   Server构架--> 数据库构架--> 物理数据库构架--> 事务日志构架--> 截断事务日志 你用 '管理 '-> '数据库维护计划 '来做 
选择数据库-> 从数据库文件中删除未使用的空间 
当数据库的大小超过n   MB   时收缩数据库   保留   10   %   的数据空间作为可用空间,这样可以调度执行,不需要手工操作了 

Answer 6

我是楼主：
       请问我用DBCC DBREINDEX (tbl_cmn_view,'',60)返回值为什么是false

Answer 7

DBCC DBREINDEX 用法
重建指定数据库中表的一个或多个索引。
语法
DBCC DBREINDEX
    (    [ 'database.owner.table_name'   
            [ , index_name
                [ , fillfactor ]
            ]
        ]
    )    
参数
'database.owner.table_name'
是要重建其指定的索引的表名。数据库、所有者和表名必须符合标识符的规则。有关更多信息，请参见使用标识符。如果提供 database 或 owner 部分，则必须使用单引号 (') 将整个 database.owner.table_name 括起来。如果只指定 table_name，则不需要单引号。
index_name
是要重建的索引名。索引名必须符合标识符的规则。如果未指定 index_name 或指定为 ' '，就要对表的所有索引进行重建。
fillfactor
是创建索引时每个索引页上要用于存储数据的空间百分比。fillfactor 替换起始填充因子以作为索引或任何其它重建的非聚集索引（因为已重建聚集索引）的新默认值。如果 fillfactor 为 0，DBCC DBREINDEX 在创建索引时将使用指定的起始 fillfactor。
同样在Query Analyzer中输入命令：
dbcc dbreindex('database_name.dbo.Employee','',90)
然后再用DBCC SHOWCONTIG查看重构索引后的结果：
DBCC SHOWCONTIG scanning 'Employee' table...
Table: 'Employee' (1195151303); index ID: 1, database ID: 53
TABLE level scan performed.
- Pages Scanned................................: 178
- Extents Scanned..............................: 23
- Extent Switches..............................: 22
- Avg. Pages per Extent........................: 7.7
- Scan Density [Best Count:Actual Count].......: 100.00% [23:23]
- Logical Scan Fragmentation ..................: 0.00%
- Extent Scan Fragmentation ...................: 0.00%
- Avg. Bytes Free per Page.....................: 509.5
- Avg. Page Density (full).....................: 93.70%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
通过结果我们可以看到Scan Denity为100%。
******