在线索引操作会在操作开始时和操作结束时对资源上短暂的锁。这有可能导致严重的阻塞问题
收缩文件的过程非常影响性能,这个过程需要移动大量数据从而造成大量IO,这个过程会被记录到日志从而造成日志暴涨,相应的,还会占去大量的CPU资源
市面上大肆宣传数据库镜像技术可以在故障发生后,立即检测到错误并进行故障转移
数据库镜像的故障转移既可以自动发起,也可以手动发起
TempDB的文件没有必要分布在多个存储器之间。如果你看到PAGELATCH类型的等待,即使你进行了分布也不会改善性能,而如果PAGEIOLATCH型的等待,或许你需要多个存储器,但这也不是必然-有可能你需要讲整个TempDB迁移到另一个存储系统,而不是仅仅为TempDB增加一
当日志文件在手动增长,自动增长和创建时都会进行填零初始化操作。但是请不要把这个过程和定期清除日志的过程搞混
我已经听过很多关于数据修复可以做什么、不可以做什么、什么会导致数据损坏以及损坏是否可以自行消失。其实我已经针对这类问题写过多篇博文,因此本篇博文可以作为“流言终结者”来做一个总结,希望你能有收获
从旧的实例升级上来的数据库不会自动开启页校验和,除非你显式使用ALTERDATABASEdatabasenameSETPAGE_VERIFYCHECKSUM进行开启。而在SQLServer2005或2008新建的数据库页校验和是默认开启的
由于FileStream数据容器(指的是存放FileStream文件的NTFS文件夹,杜撰出来的术语)必须像数据文件或日志文件那样符合本地存储策略-也就是说,这个数据容器必须放在对于运行SQLServer的WindowsServer是本地存储
这个误区也同样流传已久,我想是时候通过一些Demo进行揭穿了
事务日志备份会备份自上次事务日志备份以来所有的事务日志(如果从来没有过日志备份的话,那就从上一次完整备份开始)。有好几种类型的操作会中断事务日志的连续性,也就是说除非重新开始新的日志链,SQLServer无法再进行日志备份
SQLServer中没有任何一项操作可以修复数据损坏。损坏的页当然需要通过某种机制进行修复或是恢复-但绝不是通过重启动SQLServer,Windows亦或是分离附加数据库
资源调控器无法调控IO,希望下一个版本的SQLServer支持调控IO,调控IO对于对于减少对于大表的scan操作带来的性能影响很有帮助
在SQLServer2005和之前的版本,页锁会直接升级到表锁。在SQLServer2005或SQLServer2008,你可以通过如下跟踪标志改变锁升级的行为
本系列文章一直所没有触及的就是有关”还原(Restore)”的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步。
填充因子仅仅在索引创建或重建时生效,SQLServer存储引擎并不会一直保证页内的空闲值和填充因子保持一致
嵌套事务可不会像其语法表现的那样看起来允许事务嵌套。我真不知道为什么有人会这样写代码,我唯一能够想到的就是某个哥们对SQLServer社区嗤之以鼻然后写了这样的代码说:“玩玩你们”
一直以来我们遍历字符串的都是通过后台程序,这里分享下用sql语句实现的代码,需要的朋友可以参考下
mssql关于一个表格结构的另外一种显示(表达意思不变)接下来介绍实现方法,感兴趣的朋友可以了解下哦
有时候我们需要各种各样的格式的时间,sqlserver自带的一些GETDATE函数就可以帮我们完成,这里分享下方便需要的朋友