MYSQL教程之教你怎样减少SQL SERVER日记文件

DBaaS系统本身并不提供面对面访问或个人客户关系或持续不断的支持MySQL学习教程。这些就是需要解决方案提供商的原因。他们帮助客户选择正确的解决方案、规划集成和迁移战略，然后协助实施。　　头几天也碰着日记文件过年夜的成绩，数据库实践巨细为600M,日记文件实践巨细为33M,但日记文件占用空间为2.8G!!!
　　试了多种体例，SHIRNKDATABASE，TRUNCATELOGFILE,都没举措将文件减少。不管怎样，这应当算SQLSERVER的一个BUG吧。
　　厥后找到上面的代码，就能够将日记文件减少到本人想要的巨细了。把代码COPY到查询剖析器里，，然后修正个中的3个参数(数据库名，日记文件名，和方针日记文件的巨细)，运转便可(我已用过量次了)
　　-----
　　SETNOCOUNTON
　　DECLARE@LogicalFileNamesysname,
　　@MaxMinutesINT,
　　@NewSizeINT
　　USEMarias--要操纵的数据库名
　　SELECT@LogicalFileName=Marias_log,--日记文件名
　　@MaxMinutes=10,--Limitontimeallowedtowraplog.
　　@NewSize=100--你想设定的日记文件的巨细(M)
　　--Setup/initialize
　　DECLARE@OriginalSizeint
　　SELECT@OriginalSize=size
　　FROMsysfiles
　　WHEREname=@LogicalFileName
　　SELECTOriginalSizeof+db_name()+LOGis+
　　CONVERT(VARCHAR(30),@OriginalSize)+8Kpagesor+
　　CONVERT(VARCHAR(30),(@OriginalSize*8/1024))+MB
　　FROMsysfiles
　　WHEREname=@LogicalFileName
　　CREATETABLEDummyTrans
　　(DummyColumnchar(8000)notnull)
　　DECLARE@CounterINT,
　　@StartTimeDATETIME,
　　@TruncLogVARCHAR(255)
　　SELECT@StartTime=GETDATE(),
　　@TruncLog=BACKUPLOG+db_name()+WITHTRUNCATE_ONLY
　　DBCCSHRINKFILE(@LogicalFileName,@NewSize)
　　EXEC(@TruncLog)
　　--Wrapthelogifnecessary.
　　WHILE@MaxMinutes>DATEDIFF(mi,@StartTime,GETDATE())--timehasnotexpired
　　AND@OriginalSize=(SELECTsizeFROMsysfilesWHEREname=@LogicalFileName)
　　AND(@OriginalSize*8/1024)>@NewSize
　　BEGIN--Outerloop.
　　SELECT@Counter=0
　　WHILE((@Counter<@OriginalSize/16)AND(@Counter<50000))
　　BEGIN--update
　　INSERTDummyTransVALUES(FillLog)
　　DELETEDummyTrans
　　SELECT@Counter=@Counter+1
　　END
　　EXEC(@TruncLog)
　　END
　　SELECTFinalSizeof+db_name()+LOGis+
　　CONVERT(VARCHAR(30),size)+8Kpagesor+
　　CONVERT(VARCHAR(30),(size*8/1024))+MB
　　FROMsysfiles
　　WHEREname=@LogicalFileName
　　DROPTABLEDummyTrans
　　SETNOCOUNTOFF
<Pstyle="TEXT-INDENT:2em">
“通过有能力的DBA的一个简单计划，MySQL可以达到令人难以想像的运行速度，”一位资深DBA如此表示。MySQL中没有多余的功能来拖累CPU或占用内存。

习惯敲命令行的朋友可能会爽一些。但是功能有限。适合机器跑不动SQLServerManagementStudio的朋友使用。

我是新手，正在学习数据库和操作系统，深感理论的泛广，唯有一步一步来，但是又感觉时间不够，收集了很多资料却总是没能认真的看完，希望有一个讨论板块，大家共同解决，共同分享，共同努力

语句级快照和事务级快照终于为SQLServer的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！

可以动态传入参数，省却了动态SQL的拼写。

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

SQLServer的异构移植功能个人感觉最好了。（如果对比过SQLServer的链接服务器和Oracle的透明网关的朋友会发现SQLServer的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。）

可以动态传入参数，省却了动态SQL的拼写。