MSSQL编程：有关日记紧缩

Mysql的存储引擎接口定义良好。有兴趣的开发者可以通过阅读文档编写自己的存储引擎。紧缩
SETQUOTED_IDENTIFIEROFF
GO
SETANSI_NULLSOFF
GO


CREATEPROCEDUREstrink_logspace
AS
SETNOCOUNTON
DECLARE@LogicalFileNamesysname,
@MaxMinutesINT,
@NewSizeINT

SELECT@LogicalFileName=rtrim(name),
@MaxMinutes=10,--最年夜实行工夫
@NewSize=10--最小空间
fromsysfileswherestatus&0x40=0x40

--Setup/initialize
DECLARE@OriginalSizeint
SELECT@OriginalSize=size--in8Kpages
FROMsysfiles
WHEREname=@LogicalFileName

SELECTdb_name()+日记原始巨细+
CONVERT(VARCHAR(30),@OriginalSize)+pages/8K或+
CONVERT(VARCHAR(30),(@OriginalSize*8/1024))+MB
FROMsysfiles
WHEREname=@LogicalFileName

CREATETABLEDummyTrans
(DummyColumnchar(8000)notnull)

--Wraplogandtruncateit.
DECLARE@CounterINT,
@StartTimeDATETIME,
@TruncLogVARCHAR(255)
SELECT@StartTime=GETDATE(),
@TruncLog=BACKUPLOG[+db_name()+]WITHTRUNCATE_ONLY
--Tryaninitialshrink.
DBCCSHRINKFILE(@LogicalFileName,@NewSize)

EXEC(@TruncLog)

--Wrapthelogifnecessary.
WHILE@MaxMinutes>DATEDIFF(mi,@StartTime,GETDATE())--timehasnotexpired
AND@OriginalSize=(SELECTsizeFROMsysfilesWHEREname=@LogicalFileName)--theloghasnotshrunk
AND(@OriginalSize*8/1024)>@NewSize--Thevaluepassedinfornewsizeissmallerthanthecurrentsize.
BEGIN--Outerloop.
SELECT@Counter=0
WHILE((@Counter<@OriginalSize/16)AND(@Counter<50000))
BEGIN--update
INSERTDummyTransVALUES(FillLog)--Becauseitisacharfielditinserts8000bytes.
DELETEDummyTrans
SELECT@Counter=@Counter+1
END--update
EXEC(@TruncLog)--Seeifatruncofthelogshrinksit.
END--outerloop

DBCCSHRINKFILE(@LogicalFileName,@NewSize)

SELECTdb_name()+日记最初巨细+
CONVERT(VARCHAR(30),size)+pages/8K或+
CONVERT(VARCHAR(30),(size*8/1024))+MB
FROMsysfiles
WHEREname=@LogicalFileName
DROPTABLEDummyTrans
PRINT***数据库日记紧缩乐成***
SETNOCOUNTOFF

GO
SETQUOTED_IDENTIFIEROFF
GO
SETANSI_NULLSON
GO

--used
execstrink_logspace
MySQL是一个开放源码的小型关联式数据库管理系统，开发者为瑞典MySQLAB公司。目前MySQL被广泛地应用在Internet上的中小型网站中。

连做梦都在想页面结构是怎么样的，绝非虚言

无法深入到数据库系统层面去了解和探究

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

无法深入到数据库系统层面去了解和探究

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

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。