面向 OLTP 应用程序的重要 SQL Server 2005 性能问题
面向 OLTP 应用程序的重要 SQL Server 2005 性能问题
OLTP 工作负荷的特征是存在大量相似的小型事务。
在检查数据库设计、资源利用和系统性能的重要性时，请务必牢记这些特征。下面简述面向 OLTP
应用程序的重要性能瓶颈或缺陷。
数据
库设计问题
常用查询存在过多的表联接。在 OLTP 应用程序中过多使用联接将导致查询运行缓慢，
浪费系统资源。通常，应该重新设计数据库，避免需要 5 个或 5 个以上表联接的频繁操作。
频繁更新（包括插入、更新和删除）的表中存在过多的索引导致额外的索引维护开销。通常，OLTP 数据库的设计中应该将索引数保持为正常运转前提下的最小值，这同样是由于大量相似事务与索引维护成本共同作用的结果。
由于缺失索引，导致大量 IO，如表和范围的扫描。根据定义，OLTP 事务不应要求大量 IO，并且应该接受检查。
未使用的索引在插入、更新和删除中导致索引维护成本，而对任何用户都没有用。
应该清除未使用的索引。任何使用过的索引（通过选择、更新或删除操作）都出现在 sys.dm_db_index_usage_stats 中。因此，任何已定义但不包括在此 DMV 中的
索引自上次重新启动 SQL Server 以来尚未使用过。
CPU
瓶
颈
信号等待时间超过总等待时间的 25%。请参阅 sys.dm_os_wait_stats 中的信号等待时间和总等待时间。信号等待时间用于度量可运行队列等待 CPU 时所花费的时间。信号等待时间值很高说明出现 CPU 瓶颈。
计
划重用小于 90%。查询计划用于执行某个查询。OLTP 工作负荷建议使用计划重用，因为重新创建相同的计划（用于相似或相同的事务）是对 CPU
资源的浪费。比较 SQL Server SQL Statistics：batch requests/sec 与 SQL
compilations/sec。按照如下公式计算计划重用：计划重用 =（批处理请求数 — SQL
编译数）/批处理请求数。计划重用规则的特例：SQL 2005 SP2
中不缓存（而不是重用）零成本计划。使用零成本计划的应用程序具有较低的计划重用，但这不是性能问题。
并行等待类型 cxpacket 超过总等待时间的 10%。并行牺牲 CPU 资源换取执行速度。如果有大量 OLTP，并行查询通常会降低 OLTP 吞吐量，所以应尽量避免。有关等待统计信息，
请参阅 sys.dm_os_wait_stats。
内存瓶
颈
Average
Page Life Expectancy 持续较低。请参阅 Perfmon 对象 SQL Server Buffer Manager 中的
Average Page Life Expectancy 计数器（表示一页在缓存中停留的平均
秒数）�
相关文档：
系统环境：Windows 7
软件环境：Visual C++ 2008 SP1 +SQL Server 2005
本次目的：编写一个航空管理系统
这是数据库课程设计的成果，虽然成绩不佳，但是作为我用VC++ 以来编写的最大程序还是传到网上，以供参考。用VC++ 做数据库设计并不容易，但也不是不可能。以下是我的程序界面，后面 ......
一直对时间戳的概念模糊，并且网上也有很多朋友也都误认为：是一个时间字段，每次增加数据时，填入当前的时间值。导致也误导了很多朋友。
这次看了很多资料，纠正一下这个错误，自己也搞清楚：数据库中自动生成的唯一二进制数字，与时间和日期无关的， 通常用作给表行加版本戳的机制。存储大小为 8 个字节。
&nbs ......
DATEDIFF
返回跨两个指定日期的日期和时间边界数。
一、 语法
DATEDIFF ( datepart , startdate , enddate )
二、参数
datepar ......
为了公司考勤系统的需要
编写的几个简单存储过程(可以手动运行,也可以设置事务自动运行!感觉还行比较通用,写出来共享下)
Calendar表结构很简单,2个字段:
fdDate 日期
fdType 考勤类型(工作日N,周末W,节假日H[需要根据需要自己修改])
--判断一段时间范围内的工作日（N）和周末（W）
Create PR ......
