数据库高手请进 数据文件过大的问题

1.5 g 的数据库是很小的库了！这个量级正常是不应该存在慢的问题。

1.慢可能是服务器的配置过低，尤其是阿里云服务器租用的配置太低了！感觉你说所的找不到存储过程好像就是阿里云最低配的问题。

2.你们还用存储过程，和我们以前的系统一样，所有的业务逻辑都是存储过程完成，所以所有的压力都在数据库服务器上，服务器就容易卡，用存储过程还无法负载均衡。

3.表的索引缺失或不合理，很重要的原因。

4.使用了大量的触发器，触发器是开始一下爽，后来苦一生。坚决不用触发器，数据量大这个是要命的。

5.存储过程里使用大量的link 访问其他数据库服务器，尤其是link 给远程库写数据；如果还写远程数据包含在分布式事务里这就更要命了。

日志1g 慢和它没一毛钱关系，就是占一点空间而已

清理sql server 2008日志步骤如下:

1.将数据库设置成 简单 模式

选择要收缩的数据库，点右键 属性->选项，选择 简单模式

2.选择任务->收缩->文件

3.选择日志

或者用如下语句

代码

USE [master]

GO

ALTER DATABASE DNName SET RECOVERY SIMPLE WITH NO_WAIT

GO

ALTER DATABASE DNName SET RECOVERY SIMPLE

GO

USE DNName

GO

DBCC SHRINKFILE (N'LogFileName' , 0,TRUNCATEONLY)

GO

USE [master]

GO

ALTER DATABASE DNName SET RECOVERY FULL WITH NO_WAIT

GO

ALTER DATABASE DNName SET RECOVERY FULL

GO

SQL Server 2000要清理日志使用的是dump语句，但是在SQL Server2008里，这个语句不管用了，如果日志文件很大，比如超过1G，就需要截断一下日志文件以加快sqlserver的运行速度，在SQL Server2008里，方法改为：

有数据库 xxdb 在 SQL Server 2008 下，日志文件已经超过1G。

以往使用BACKUP语句－BACKUP LOG xxdb WITH NO_LOG 已经失效，在查阅 MSDN 之后发现 MS 提供的标准截断日志语句已经变为了 “BACKUP LOG 语句不指定 WITH COPY_ONLY”

使用语句 BACKUP LOG xxdb to disk='x:\work\1.bak' 成功将日志文件备份，并截断日志文件。这里x:代表你想要备份文件的盘符。

然后使用 DBCC SHRINKFILE (xxdb_log,10) 收缩日志文件到 10M

总结：

完整的收缩日志文件的 T-SQL 语句：

BACKUP LOG xxdb to disk='x:\work\1.bak'

DBCC SHRINKFILE (xxdb_log,10)

GO

--

BACKUP LOG <db_name>to disk=<'backupfilename'>

DBCC SHRINKFILE (<log_filename>,10)

GO

里面的x:\work是随意设置的。当然也可以收缩到比如5M或1M。

在用的：

USE[master]

GO

ALTERDATABASEYHDBSETRECOVERYSIMPLEWITHNO_WAIT

GO

ALTERDATABASEYHDBSETRECOVERYSIMPLE--简单模式

GO

USEYHDB

GO

DBCCSHRINKFILE(N'YHDB_log', 11,TRUNCATEONLY)

GO

USE[master]

GO

ALTERDATABASEYHDBSETRECOVERYFULLWITHNO_WAIT

GO

ALTERDATABASEYHDBSETRECOVERYFULL--还原为完全模式

GO

您好：

--日志备份

BACKUP LOG DatangBusinessSys to disk='E:\BackUpDb\DatangBusinessSys_backup.bak'

--日志收缩

DBCC SHRINKFILE (N'DatangBusinessSys_log' , 11, TRUNCATEONLY)

DBCC SHRINKFILE (xxdb_log,10)

--检查未提交的数据

DBCC LOGINFO('DatangBusinessSys')

备份数据库，然后备份日志，截断日志，最后收缩日志文件。

---