怀疑一切，但不否定一切

冗余反正是绕不过去的话题，我认为冗余设计应该结合业务需求和性能考量，最重要应该出自DBA/DBD之手，而不是程序员。

比较全面。

写得很好。临时表和表变量之争，应该是怎么界定“大量数据”，其它好去解决。没有相关量化的指引。。。

来学习下看看。

Microsoft Windows [版本 5.2.3790]
(C) 版权所有 1985-2003 Microsoft Corp.

C:\Documents and Settings\Administrator>diskpart

Microsoft DiskPart Copyright (C) 1999-2001 Microsoft Corporation.
On computer: WLB

DISKPART> select disk 0

磁盘 0 现在是所选磁盘。

DISKPART> list partition

分区 ### 类型 大小 偏移
------------- ---------------- ------- -------
分区 1 主要 20 GB 32 KB
分区 2 扩展的 279 GB 20 GB
分区 3 逻辑 39 GB 20 GB
分区 4 逻辑 39 GB 59 GB
分区 5 逻辑 200 GB 98 GB

DISKPART> create partition parmary align=64

Microsoft DiskPart 版本 5.2.3790.3959

EFI - 创建 EFI 系统分区。
EXTENDED - 创建扩展分区。
LOGICAL - 创建逻辑驱动器。
MSR - 创建 Microsoft 保留分区。
PRIMARY - 创建主要分区。

DISKPART> select disk 0

磁盘 0 现在是所选磁盘。

DISKPART> list partition

分区 ### 类型 大小 偏移
------------- ---------------- ------- -------
分区 1 主要 20 GB 32 KB
分区 2 扩展的 279 GB 20 GB
分区 3 逻辑 39 GB 20 GB
分区 4 逻辑 39 GB 59 GB
分区 5 逻辑 200 GB 98 GB

DISKPART> create partition primary align=64

DiskPart 成功地创建了指定分区。

DISKPART> list partition

分区 ### 类型 大小 偏移
------------- ---------------- ------- -------
分区 1 主要 20 GB 32 KB
分区 2 扩展的 279 GB 20 GB
分区 3 逻辑 39 GB 20 GB
分区 4 逻辑 39 GB 59 GB
分区 5 逻辑 200 GB 98 GB
* 分区 6 主要 8033 KB 298 GB
这是我的执行结果，还请楼主赐教。

楼主是在哪，这么厉害啊！

好文章，帮大忙了。

不是在域环境中配置的，用的证书，找个日志有没有什么好的解决方法哦，我的见证服务还是不的行，还是报这个错

@xchit
你是在域环境中配置吗？一般生产环境都在域中创建，确保域账号有相应的权限就可以了。
日志满了的原因可能是因为下面三个原因：
1、你没有定期对日志进行备份
2、镜像服务器挂起导致备份日志时不能截断日志
3、事务操作中操作的数据量太大导致即使备份日志也不能截断日志

你好,做数据库镜像，做见证服务器的时候报错
“无法将 ALTER DATABASE 命令发送到远程服务器实例 'TCP://192.168.3.97:6022'。数据库镜像配置未更改。请确保该服务器已连接，然后重试。
”
有没有解决方法呀，还有因为要产生大量的日志文件，给日志设置的空间，没几天都慢了，这么办呀，请帮我分析哈，谢谢了

请问下楼主最初当上DBA时都要些啥条件啊，能否说些经验

@风海迷沙
大小除了和记录数有关外，重要的还是和每条记录里包含些什么东西有关。因此不能只从记录数多少来衡量数据库的大小。 多谢各位回复，请不要只关心数据库有多大。能不能给出些更具体的解决办法？

@笨笨的考拉熊
具体业务要求我也不是很清楚，程序上有没有问题我就更不清楚了。只是听项目人员说客户要求这么做，而且历史数据保留越久越好，以备随时可以查询。更主要的原因还是因为有些工单少上传了或是有错误需要重传了，这时就要对原有操作重新进行一次。我想可以把它当成是数据集市，不知道有什么好的办法来解决空间和备份的问题？谢谢

按数据的创建时间字段做表分区没什么不好吧？为什么不呢？

Sorry，搞错了，我搞成OLAP了

不明白每天增量才几千几万条的OLTP数据库为什么会到600G，难道老数据从来不删么。需要尽量保留历史数据，是设计方法上有问题。
我们这里每天100多万条的增量，数据库也才80G而已

@Jason Cui
如果字体太小，可以按住CTRL，然后滚动鼠标，就可以调整字体大小了。如有好方案，请赐教！

@Cheney Shue
项目的具体要求：每天会从POS中导入很多工单。每天会根据某些要求对这么新的数据进行某些操作，偶尔还要涉及到历史数据。所以必须要尽量保留相关的历史数据以备使用。如果把历史数据分库或分机器存储，程序就要做相应的调整，如此不知道用什么办法更为合适？你说的5T的数据是如何存储和备份的，能不能分享下经验？我的MSN：ht_f@hotmail.com

@凉面
具体情况具体分析吧，最有用的办法就是让老板投资存储设备

@Cheney Shue
不好意思啊，水平有限，我就是做这个工作的。不知道你有什么好的方法分享一下？

如果只是为了查询方便,做报表方便,我是强烈不建议冗余的.感觉为了这么点方便损失违反模式而带来的数据异常实在是没有必要.如果是为了性能,另当别论.

我们公司的数据库设计大多数是有数据冗余的，为了查询方便，做报表方便。。。合理的数据冗余的设计弊大于利。

冗余得看应用场景吧 而且很多时候要看维护成本和业务要求的严谨程度

着有什么好说的，随便翻出一本数据库方面的书籍都会这样说。

Oracle里面的哪个物化视图 更是这样的一个经典

有时候冗余是为了获得更好的性能

恩，空间换时间

没有看懂

THX!
在看了，还没看到编译计划这些~~

@付博
《Inside Microsoft SQL Server 2005 Query Tuning and Optimization》你可以看下这本书

感谢楼主分享成果，不知可否能公开资料来源？万分感谢！

如果基于研究有对实际操作的指导就更好了。不过怎么说，顶

比较高深的东西，收藏了

学习了一些基础东西，有些东西还是看不来，
谢谢

沙发，很不错，顶一个，呵呵

@lidong＿
主要是看I/O、成本开销的比例，以及是否会因为选择度的问题造成错误的执行计划。

我很奇怪楼主是如何证明优化后的查询比最初的查询性能高．

怀疑一起，为什么不否定一切。

然后再通过否定之否定升华。

@Garnett_KG
这个文档中并没有记录，如果使用DBCC FREEPROCCACHE就不用说了，全部缓存就都清空了。这在生产机上是万万不能执行的。不过要是只有一个数据库时，如果sys.dm_os_wait_stats视图中wait_type为SOS_RESERVEDMEMBLOCKLIST有很长的等待时间时清除缓存会暂时解决这种类型的等待。这种等待是因为查询中有大量的参数或是IN中包含太多的值所引起的，可以把IN中的值放入表变量或临时表中，然后再和表做联接以避免出现这种类型的等待。

DBCC FLUSHPROCINDB(@dbid)

mybe this is sqlserver2005's bug .

@Cheney Shue
当database置于offline后，shared pool中的sql cache自然就没用了。
你这里说的是对offline的数据库来说的吧。按理说，通过元数据是可以查看此缓存计划是与哪个数据库相关联的，可是为什么要把其它数据库的所有的缓存计划都清空呢？

从性能上考虑，当数据库需要某个block时，会从data file中将block读到buffer cache中，此block会在buffer cache中保留很长时间，block经过update,insert等dml后，会成为dirty block。
DBWR会在必要时将dirty block从buffer cache回写到data file中。
将Database置于offline，会强制checkpoint，buffer cache中的大量数据需要写入data file。而uncommit的dml会rollback，需要从undo读取数据。
因此导致数据库的CPU usage和i/o提升。
当database置于offline后，shared pool中的sql cache自然就没用了。

以上情况是就oracle database来说的，sql server也类似。oracle db有机制保持一致性前提下，分离数据库，但不提升额外的系统资源。

收藏一下。

不错！！

如果在最后做一下总结就更好.

@RicCC
自动重新编译的条件有两种：一是因为所引用对象的结构发生变化，二是因为统计信息发生较大变化。但是统计信息的变化并不能立即反应出来，我在《依赖自动统计对性能的影响》里已经举例说明。

缓存的执行计划会跟踪编译时使用到的关键信息，有编译时机器运行环境相关的，有元数据相关的，也包括统计信息
统计信息变化较大，达到需要重编译的条件时，sql server会自动重编译缓存的执行计划
没必要这样认为干预这个过程

其实嘛，直接写就可以了，运行后慢了再说。呵呵。
当然有一定的风险，但是如果只是纸上谈兵的话，好像也没有太大的帮助。

@金色海洋（jyk）
书中没有不正确的观点，只是有时如果一直按照书中所举示例的写法，会因为缓存的原因造成错误的选择。因此在选择度有很大差异时，应该注意一下SQL的写法。
SQLSERVER因为选择度问题造成很多问题，这也是我一直很郁闷的一个问题，如果有什么好的办法，请分享一下你的经验。
另外，很不好意思，我在WORD中排版后，然后直接用office的发布功能，传上来格式总是乱的。调来调去，总是调不好格式。

确实是难以看懂，有时间仔细看一遍。

-----------------------------------------------
快速开发与工业化代码生成
http://www.cnblogs.com/mrhgw/archive/2008/10/09/1307247.html
http://www.mrhgw.cn

难道您没有看我举得那两个SQL语句吗，还是说我的例子是错误的。

明明第一条SQL语句没有进行表遍历呀。