MSSQL编程：sql server日记文件总结及日记满的处置...

有了数据以后，我们就要想一个比较统一的方法来闪回。上面我们说了对于DML操作，可以通过反向执行所有逆操作来实现，对于语句里面的DDL，只能直接跳过。原因是一个DDL不一定有直接的逆操作。server买卖日记（Transactionlogs）是数据库布局中十分主要但又常常被疏忽的部分。因为它其实不像数据库中的schema那样活泼，因而很少有人存眷买卖日记。　　买卖日记是针对数据库改动所做的纪录，它能够纪录针对数据库的任何操纵，并将纪录了局保留在自力的文件中。关于任何每个买卖历程，买卖日记都有十分周全的纪录，依据这些纪录能够将数据文件恢复成买卖前的形态。从买卖举措入手下手，买卖日记就处于纪录形态，买卖过程当中对数据库的任何操纵都在纪录局限，直到用户点击提交或前进后才停止纪录。每一个数据库都具有最少一个买卖日记和一个数据文件。
　　出于功能上的思索，SQLServer将用户的修改存进缓存中，这些改动会当即写进买卖日记，但不会当即写进数据文件。买卖日记会经由过程一个标志点来断定某个买卖是不是已将缓存中的数据写进数据文件。当SQLServer重启后，它会检察日记中最新的标志点，并将这个标志点前面的买卖纪录抹往，由于这些买卖纪录并没有真实的将缓存中的数据写进数据文件。这能够避免那些中止的买卖修正数据文件。
　　保护买卖日记
　　由于良多人常常忘记买卖日记，因而它也会给体系带来一些成绩。跟着体系的不休运转，日记纪录的内容会愈来愈多，日记文件的体积也会愈来愈年夜，终极招致可用磁盘空间不敷。除非一样平常事情中常常对日记举行清算，不然日记文件终极会侵犯分区内的全体可用空间。日记的默许设置为不限容量，假如以这类设置事情，它就会不休收缩，终极也会占有全体可用空间。这两种情形城市招致数据库中断事情。
　　对买卖日记的一样平常备份事情能够无效的避免日记文件太过损耗磁盘空间。备份历程会将日记中不再必要的部分截除。截除的办法是起首把旧纪录标志为非举动形态，然后将新日记掩盖到昔日志的地位上，如许就能够避免买卖日记的体积不休收缩。假如没法对日记举行常常性的备份事情，最好将数据库设置为"复杂恢复形式"。在这类形式下，体系会强迫买卖日记在每次纪录标志点时，主动举行截除操纵，以新日记掩盖昔日志。
　　截除历程产生在备份或将旧标志点标为非举动形态时，它使得旧的买卖纪录能够被掩盖，但这其实不会削减买卖日记实践占用的磁盘空间。就算不再利用日记，它仍然会占有必定的空间。因而在保护时，还必要对买卖日记举行紧缩。紧缩买卖日记的办法是删除非举动纪录，从而削减日记文件所占用的物理硬盘空间。
　　经由过程利用DBCCSHRINKDATABASE语句能够紧缩以后数据库的买卖日记文件，DBCCSHRINKFILE语句用来紧缩指定的买卖日记文件，别的也能够在数据库中激活主动紧缩操纵。当紧缩日记时，起首会将旧纪录标志为非举动形态，然后将带有非举动标志的纪录完全删除。依据所利用的紧缩体例的分歧，你大概不会当即看到了局。在幻想情形下，紧缩事情应当选在体系不长短常忙碌的时段举行，不然有大概影响数据库功能。
　　恢单数据库
　　买卖纪录备份能够用来将数据库恢复到某一指定形态，但买卖纪录备份自己不敷以完成恢单数据库的义务，还必要备份的数据文件介入恢停工作。恢单数据库时，起首举行的是数据文件的恢停工作。在全部数据文件恢复完成前，不要将其设为完成形态，不然买卖日记就不会被恢复。当数据文件恢复完成，体系会经由过程买卖日记的备份将数据库恢复成用户但愿的形态。假如在数据库最初一次备份后，存在多个日记文件的备份，备份程序会依照它们创建的工夫顺次将其恢复。
　　另外一种被称为logshipping的历程能够供应更强的数据库备份才能。当logshipping设置好后，它能够将数据库全部复制到另外一台服务器上。在这类情形下，买卖日记也会按期发送到备份服务器上供恢单数据利用。这使得服务器一向处于热备份形态，当数据产生改动时它也随之更新。另外一个服务器被称作监督（monitor）服务器，能够用来监督按划定工夫距离发送的shipping旌旗灯号。假如在划定工夫内没有收到旌旗灯号，监督服务器会将这一事务纪录到事务日记。这类机制使得logshipping常常成为劫难恢复企图中利用的计划。
　　功能优化
　　买卖日记对数据库有主要感化，同时它对体系的全体功能也有必定影响。经由过程几个选项，我们能够对买卖日记的功能举行优化。因为买卖日记是一个一连的磁盘写进历程，在这傍边不会产生读取举措。因而将日记文件放在一个自力的磁盘，对优化功能有必定感化。
　　另外一项优化措施与日记文件的体积有关。我们能够设置日记文件的体积不凌驾硬盘空间的百分之几，大概断定它的巨细。假如将其设置的过年夜会华侈磁盘空间，而假如设置的太小则会强迫纪录文件不休实验扩大，招致数据库功能下落。
　　
　　事件日记文件TransactionLogFile是用来纪录数据库更新情形的文件，扩大名为ldf。
　　在SQLServer7.0和SQLServer2000中，假如设置了主动增加功效，事件日记文件将会主动扩大。
　　一样平常情形下，在可以包容两次事件日记截断之间产生的最年夜数目的事件时，事件日记的巨细是不乱的，事件日记截断由反省点大概事件日记备份触发。
　　但是，在某些情形下，事件日记大概会变得十分年夜，乃至用尽空间或变满。一般，在事件日记文件占尽可用磁盘空间且不克不及再扩大时，您将收到以下毛病动静：
　　Error:9002,Severity:17,State:2
　　Thelogfilefordatabase%.*lsisfull.
　　除呈现此毛病动静以外，SQLServer还大概由于短少事件日记扩大空间而将数据库标志为SUSPECT。有关怎样今后情况中恢复的其他信息，请拜见SQLServer联机匡助中的“磁盘空间不敷”主题。
　　
　　别的，事件日记扩大大概招致以下情况：
　　・十分年夜的事件日记文件。
　　・事件大概会失利并大概入手下手回滚。
　　・事件大概会用很长工夫才干完成。
　　・大概产生功能成绩。
　　・大概产生堵塞征象。
　　
　　缘故原由
　　事件日记扩大大概因为以下缘故原由或情况而产生：
　　・未提交的事件
　　・十分年夜的事件
　　・操纵：DBCCDBREINDEX和CREATEINDEX
　　・在处置务日记备份复原时
　　・客户端使用程序不处置一切了局
　　・查询在事件日记完成扩大之前超时，您收到假的“LogFull”毛病动静
　　・未复制的事件
　　
　　办理办法
　　日记文件满而形成SQL数据库没法写进文件时，可用两种办法：
　　一种办法：清空日记。
　　1．翻开查询剖析器，输出命令
　　DUMPTRANSACTION数据库名WITHNO_LOG
　　2.再翻开企业办理器--右键你要紧缩的数据库--一切义务--压缩数据库--压缩文件--选择日记文件--在压缩体例里选择压缩至XXM,这里会给出一个同意压缩到的最小M数,间接输出这个数,断定就能够了。
　　
　　另外一种办法有必定的风险性，由于SQLSERVER的日记文件不是立即写进数据库主文件的，如处置不妥，会形成数据的丧失。
　　1:删除LOG
　　分别数据库企业办理器－＞服务器－＞数据库－＞右键－＞分别数据库
　　2：删除LOG文件
　　附加数据库企业办理器－＞服务器－＞数据库－＞右键－＞附加数据库
　　此法天生新的LOG，巨细只要500多K。
　　
　　注重：倡议利用第一种办法。
　　
　　假如今后,不想要它变年夜。
　　SQL2000下利用：
　　在数据库上点右键->属性->选项->妨碍恢复-模子-选择-复杂模子。
　　或用SQL语句：
　　alterdatabase数据库名setrecoverysimple
　　
　　
　　别的，如上图中数据库属性有两个选项，与事件日记的增加有关：
　　Truncatelogoncheckpoint
　　(此选项用于SQL7.0，SQL2000中即妨碍恢复模子选择为复杂模子)
　　当实行CHECKPOINT命令时假如事件日记文件凌驾其巨细的70%则将其内容扫除在开辟数据库不时常将此选项设置为True
　　Autoshrink
　　按期对数据库举行反省当数据库文件或日记文件的未用空间凌驾其巨细的25%时，体系将会主动缩减文件使其未用空间即是25%当文件巨细没有凌驾其创建时的初始巨细时不会缩减文件缩减后的文件也必需年夜于或即是其初始巨细对事件日记文件的缩减只要在对其作备份时或将Truncatelogoncheckpoint选项设为True时才干举行。
　　
　　注重：一样平常立成创建的数据库默许属性已设好，但碰着不测情形使数据库属性被变动，请用户清空日记后，反省数据库的以上属性，以防事件日记再次充斥。
如果WHERE子句的查询条件里使用比较操作符LIKE和REGEXP，MySQL只有在搜索模板的第一个字符不是通配符的情况下才能使用索引。比如说，如果查询条件是LIKEabc%‘，MySQL将使用索引；如果查询条件是LIKE%abc’，MySQL将不使用索引。

光写几个SQL实在叫无知。

这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？

这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。

这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。

换言之，只有在不断的失败中尝试成功，而关于失败的总结却是很少的

索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。