以下有关 SQL Server 的 Microsoft Knowledge Base 文章，都是从 Microsoft 的技术支持在线网站 ( http://support.microsoft.com/support ) 中编辑的。以下文章回答了访问技术支持在线站点的用户经常提的一些问题。请单击下表中的有关问题转到感兴趣的答案。
如何避免应用程序中的死锁？
在某些条件下可能发生阻塞，这是任何基于锁定的并发系统都不可避免的特性。当第一个连接持有锁定，而第二个连接要求相冲突的锁定类型时，就会发生阻塞。这样迫使第二个连接要么等待，要么阻塞第一个。
为了得到最佳的可伸缩性、性能和并发性，应用程序和查询设计应当强调保持较短的事务路径长度，和尽可能短的锁定。多数并发性问题的基础都来自于设计应用程序和数据库时。因此，在设计时充分地了解这些问题是很重要的。否则，可能会有隐藏的性能局限性被无意地设计到应用程序中，而这种局限性在进行全面的负荷测试之前是看不出来的。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
- Q162361: Understanding and Resolving SQL Server Blocking Problems
如何改进 SQL Server 中的 DBCC 性能？
DBCC (DataBase Consistency Checker）工具是一组用于验证 SQL Server 数据库完整性的程序。在概念上，它们类似于文件系统检查程序，如 MS-DOS、Windows 95 和 Windows NT 下的 CHKDSK，以及 UNIX 下的 fsck。与文件系统检查程序一样，DBCC 在大的数据集上运行可能花费相当长的时间。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
- Q140569: How to Improve DBCC Performance on SQL Server
Microsoft SQL Server 如何处理加密？
Microsoft SQL Server 版本 6.x 允许为有多协议网络库加密选项的 16 位和 32 位客户端“无线”地加密数据。
SQL Server 依靠 Microsoft Windows NT RPC API 来执行网络通信的加密。Windows NT RPC 使用 40 位 RC4 加密，这是允许出口的最高级加密等级，因而在美国版本和国际版本间没有差异。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
- Q132224: Encryption Algorithm in the Multi-Protocol Net Library
应当如何进行 SQL Server 性能优化？
为了有效地优化 Microsoft SQL Server 的性能，应当在各种可能情况中识别能够最大地提高性能的方面，然后重点分析这些方面。否则，可能会在不能提高性能的问题上花费相当长的时间和气力。
经验显示，SQL Server 性能的最大改进得益于逻辑的数据库设计、索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中的不足引起的。如果性能是所关心的问题，那么应当先在这些方面集中精力，因为用相对少的时间投资，常常可以获得非常大的性能改进。
尽管其它的系统级性能问题，如内存、缓冲区高速缓存、硬件等等也是等待研究的问题，但经验显示，从这些方面得到的性能改进通常是渐进的。SQL Server 主要以自动方式管理可用的硬件资源，这样可以减少系统级手动调整的需要（因此，这也就是效益）。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
- Q110352: Optimizing Microsoft SQL Server Performance
建议 SQL Server 使用何种内存分配？
Microsoft SQL Server 允许使用多至 2048 MB 的虚拟内存。Windows NT 为每 32 位 Windows 应用程序提供 4GB 虚拟地址空间，其中较低的 2 GB 是每个进程私有的并供应用程序使用。而较高的 2 GB 保留给系统使用。
4 GB 地址空间由 Windows NT 虚拟管理器 (VMM) 映射到可用物理内存。可用物理内存最多可达 4 GB，这取决于硬件平台的支持。
32 位 Windows 应用程序，如 SQL Server 只能感知虚拟或逻辑地址，而不是物理地址。应用程序在指定时间可以使用多少内存（工作集）由可用物理内存和 VMM 决定。应用程序不能直接控制内存驻留。
虚拟地址系统，如 Windows NT，允许虚拟内存的过量委托，这样虚拟内存和物理内存的比率就超过 1:1。结果，较大的程序就可以运行在多种物理内存配置的机器上。但是，在多数情况下，如果使用比所有进程的平均工作集的组合多很多的虚拟内存，则会导致很差的性能。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
Q110983: Recommended SQL Server for NT Memory Configurations
导致 DBCC 页计数和 SYSINDEXES DPAGES 中反映的页计数之间差异的原因是什么？
DBCC 经常会发现实际页计数和 SYSLOGS 表的 SYSINDEXES DPAGES 中反映的页计数之间存在差异。之所以产生这种差异，是因为不是在每次记录时都更新 SYSINDEXES (DPAGES) 中的页计数，每次更新会带来过多的开销。实际情况是，直到执行 CHECKPOINT 时才保存所做的更改。
这种差异不会引起任何问题，因为 SYSINDEXES 中的值仅用于报告空间分配，并不强制执行空间分配。另外，SYSINDEXES 中偶尔错误的值从来不会影响选择访问策略，因为查询从不在 SYSLOGS 上运行。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
- Q39113: DBCC Reports Page Count Discrepancy on SYSLOGS Table
事务日志填满的原因和影响是什么？
SQL Server 事务日志可能会被填满，这样会防止数据库中进一步的 UPDATE、DELETE 或 INSERT 操作，包括 CHECKPOINT。
这通常作为错误 1105 被观察到：
Can't allocate space for object syslogs in database dbname because the logsegment is full.If you ran out of space in syslogs, dump the transaction log.Otherwise use ALTER DATABASE or sp_extendsegment to increase the size of the segment.
这可以发生在任何数据库上，包括 master 或 tempdb。
有以下几种难以预料的因素可以解释日志空间消耗的变化，如：
- 大原子事务处理，特别是大容量更新、插入或删除。
- 未提交的事务。
- 超出检查点处理程序截断带宽。
- 超出截断阈值。
- 任何上述情况的相互作用。
- 标记事务用于发布，但没有被日志阅读程序读取。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
- Q110139: Causes of SQL Transaction Log Filling Up
SQL Server 中如何支持 TCP/IP 和 Windows 套接字？
Microsoft SQL Server 版本 6.x 将标准 Windows 套接字作为 TCP/IP 协议的 IPC 方法，支持基于 Windows 或基于 Windows NT 客户端的客户端通信。已经彻底地在所支持的平台上测试过 Windows 套接字 Net-Libraries，从而可以用于连接到 Microsoft SQL Server。如果其它 TCP/IP 协议完全支持 Windows 套接字，则与那些协议使用这些 Net-Libraries 也应当能工作。但是，不保证它们在这些平台上的使用。协议提供者应当测试并声明其技术支持策略。
完全支持 Windows 套接字规范的第三方 16 位 TCP/IP 产品（Windows for Workgroups 提供的除外）也应当能够完全使用 Win16 TCP/IP 套接字 Net-Library (DBMSSOC3.DLL)。虽然没有正式地测试并支持,那些完全执行规范的产品也应当能够使用 Net-Library。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
Q107647: Connecting to SQL Server from TCP/IP Sockets Clients
引起错误日志中产生 17824、17832 和 1608 错误消息的原因是什么？
与 Microsoft SQL Server 通信相关的各种错误都有可能发生。一般说来，这些错误消息指出的不是 SQL Server 的问题，而是网络、网络配置或客户应用程序的问题。在客户端和服务器端，SQL Server 和其应用程序主要存在于 ISO（国际标准化组织）网络层上方。建立并维护可靠的网络连接的责任属于 SQL Server 以下的网络和系统层。
可能的错误包括：
服务器端错误
- 17832 Unable to read login packet(s)
- 17825 Unable to close server-side connection
- 17824 Unable to write to server-side connection
- 10058 Can't send after socket shutdown
- 10054 Connection reset by peer
- 10053 Software caused connection abort
- 1608 A network error was encountered while sending results to the front end
- 232 The pipe is being closed
- 109 The pipe has been ended
客户端错误
- 10008 Bad token from SQL Server:datastream processing out of sync
- 10010 Read from SQL Server failed
- 10018 Error closing network connection
- 10025 Write to SQL Server failed
有关此主题的详细信息，请参阅 SQL Server Books Online 中的 Administrators Companion。
相关的 Knowledge Base 文章
有关此主题和其它相关问题的详细信息，请查看 Microsoft Knowledge Base。其中有几千篇文章，回答了有关使用 Microsoft 产品的常见问题。请参见以下 Knowledge Base 文章：
- Q109787: SQL Communication Errors 17832, 17824, 1608, 232, and 109
MICROSOFT KNOWLEDGE BASE 所有信息都是以“现有状况”给出的，并没有任何的保证。Microsoft 否认任何其它明示的或默示的保证，包括特定目的的适销性和适用性的各项默示保证。在任何情况下，MICROSOFT CORPORATION 或其供应商对于任何灾难事件，包括直接事件、间接事件、附带事件、因果事件、商业利益损失，或特殊的灾难事件将不负责任，即使 MICROSOFT CORPORATION 或其供应商已经考虑过这些种灾难的可能性。某些国家不允许排除或限制因果事件或附带灾难的责任，所以上述限制可能不适用。
发表于 @ 2006年01月08日 16:15:00|评论(loading...)|编辑