打开一台windows 2003 server的Performance count，发现所有的计数器库值都变成了数值，找到了一篇微软的KB,虽然说“本文中的信息仅适用于英语版 Windows 2000”，但在文章后的适用中包括了windows 2003 server。
照着在英文版windows 2003 server执行了一遍，问题解决
微软KB链接300956
2009年5月14日星期四
Windows性能计数器的对象名显示为数字的解决办法
打开一台windows 2003 server的Performance count，发现所有的计数器库值都变成了数值，找到了一篇微软的KB,虽然说“本文中的信息仅适用于英语版 Windows 2000”，但在文章后的适用中包括了windows 2003 server。
照着在英文版windows 2003 server执行了一遍，问题解决
微软KB链接300956
2009年5月13日星期三
Google架构学习
Google架构学习
关键字: google
原文：Google Architecture
摘自:javaeye
Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。
平台
Linux
大量语言：Python，Java，C++
状态
在2006年大约有450,000台廉价服务器
在2005年Google索引了80亿Web页面，现在没有人知道数目
目前在Google有超过200个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40兆字节
目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序
BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择
堆栈
Google形象化它们的基础组织为三层架构：
1，产品：搜索，广告，email，地图，视频，聊天，博客
2，分布式系统基础组织：GFS，MapReduce和BigTable
3，计算平台：一群不同的数据中心里的机器
4，确保公司里的人们部署起来开销很小
5，花费更多的钱在避免丢失日志数据的硬件上，其他类型的数据则花费较少
可信赖的存储机制GFS(Google File System)
1，可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台
2，Google File System - 大型分布式结构化日志文件系统，Google在里面扔了大量的数据
3，为什么构建GFS而不是利用已有的东西？因为可以自己控制一切并且这个平台与别的不一样，Google需要：
-跨数据中心的高可靠性
-成千上万的网络节点的伸缩性
-大读写带宽的需求
-支持大块的数据，可能为上千兆字节
-高效的跨节点操作分发来减少瓶颈
4，系统有Master和Chunk服务器
-Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些Chunk服务器
-Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件
6，一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群
7，关键点在于有足够的基础组织来让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求
使用MapReduce来处理数据
1，现在你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢？比如你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的原因
2，MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经验就可以很容易使用一个大型分布式系统资源
3，为什么使用MapReduce？
-跨越大量机器分割任务的好方式
-处理机器失败
-可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有map和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等
4，MapReduce系统有三种不同类型的服务器
-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态
-Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件
-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作
5，例如，你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MapReduce。这将在成千上万台机器上同时进行并且所有的调整、工作调度、失败处理和数据传输将自动完成
-步骤类似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
-在MapReduce里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数
-Shuffling操作聚集键类型
-Reduction操作计算所有键值对的综合并产生最终的结果
6，Google索引操作管道有大约20个不同的map和reduction。
7，程序可以非常小，如20到50行代码
8，一个问题是掉队者。掉队者是一个比其他程序慢的计算，它阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的
9，数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。
在BigTable里存储结构化数据
1，BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万的读写
2，BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询
3，它提供查询机制来通过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据
4，商业数据库不能达到这种级别的伸缩性并且不能在成千上万台机器上工作
5，通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如，如果它们想让跨数据中心的操作更简单这个特性，它们可以内建它
6，系统运行时机器可以自由的增删而整个系统保持工作
7，每个数据条目存储在一个格子里，它可以通过一个行key和列key或者时间戳来访问
8，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列并且格式为SSTable
9，BigTable有三种类型的服务器：
-Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要则重新分配任务
-Tablet服务器为tablet处理读写请求。当tablet超过大小限制(通常是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet然后系统恢复。
-Lock服务器形成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都需要互斥
10，一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的locality选择
11，tablet尽可能的缓存在RAM里
硬件
1，当你有很多机器时你怎样组织它们来使得使用和花费有效？
2，使用非常廉价的硬件
3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.
4，Linux，in-house rack design，PC主板，低端存储
5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues
6，使用一些collocation和Google自己的数据中心
其他
1，迅速更改而不是等待QA
2，库是构建程序的卓越方式
3，一些程序作为服务提供
4，一个基础组织处理程序的版本，这样它们可以发布而不用害怕会破坏什么东西
Google将来的方向
1，支持地理位置分布的集群
2，为所有数据创建一个单独的全局名字空间。当前的数据由集群分离
3，更多和更好的自动化数据迁移和计算
4，解决当使用网络划分来做广阔区域的备份时的一致性问题(例如保持服务即使一个集群离线维护或由于一些损耗问题)
学到的东西
1，基础组织是有竞争性的优势。特别是对Google而言。Google可以很快很廉价的推出新服务，并且伸缩性其他人很难达到。许多公司采取完全不同的方式。许多公司认为基础组织开销太大。Google认为自己是一个系统工程公司，这是一个新的看待软件构建的方式
2，跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的
3，如果你自己没有时间从零开始重新构建所有这些基础组织你可以看看Hadoop。Hadoop是这里很多同样的主意的一个开源实现
4，平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子，那么你将陷入困境因为知道怎样完成这项工作的人相对较少
5，协同工作不一直是掷骰子。通过让系统中的所有部分一起工作则一个部分的改进将帮助所有的部分。改进文件系统则每个人从中受益而且是透明的。如果每个项目使用不同的文件系统则在整个堆栈中享受不到持续增加的改进
6，构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级
7，创建可进化的基础组织，并行的执行消耗时间的操作并采取较好的方案
8，不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.
9，考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。
关键字: google
原文：Google Architecture
摘自:javaeye
Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。
平台
Linux
大量语言：Python，Java，C++
状态
在2006年大约有450,000台廉价服务器
在2005年Google索引了80亿Web页面，现在没有人知道数目
目前在Google有超过200个GFS集群。一个集群可以有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以达到每秒40兆字节
目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序
BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择
堆栈
Google形象化它们的基础组织为三层架构：
1，产品：搜索，广告，email，地图，视频，聊天，博客
2，分布式系统基础组织：GFS，MapReduce和BigTable
3，计算平台：一群不同的数据中心里的机器
4，确保公司里的人们部署起来开销很小
5，花费更多的钱在避免丢失日志数据的硬件上，其他类型的数据则花费较少
可信赖的存储机制GFS(Google File System)
1，可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台
2，Google File System - 大型分布式结构化日志文件系统，Google在里面扔了大量的数据
3，为什么构建GFS而不是利用已有的东西？因为可以自己控制一切并且这个平台与别的不一样，Google需要：
-跨数据中心的高可靠性
-成千上万的网络节点的伸缩性
-大读写带宽的需求
-支持大块的数据，可能为上千兆字节
-高效的跨节点操作分发来减少瓶颈
4，系统有Master和Chunk服务器
-Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些Chunk服务器
-Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创建冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件
6，一个上线的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群
7，关键点在于有足够的基础组织来让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求
使用MapReduce来处理数据
1，现在你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢？比如你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的原因
2，MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经验就可以很容易使用一个大型分布式系统资源
3，为什么使用MapReduce？
-跨越大量机器分割任务的好方式
-处理机器失败
-可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有map和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等
4，MapReduce系统有三种不同类型的服务器
-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态
-Map服务器接收用户输入并在其基础上处理map操作。结果写入中间文件
-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操作
5，例如，你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MapReduce。这将在成千上万台机器上同时进行并且所有的调整、工作调度、失败处理和数据传输将自动完成
-步骤类似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
-在MapReduce里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数
-Shuffling操作聚集键类型
-Reduction操作计算所有键值对的综合并产生最终的结果
6，Google索引操作管道有大约20个不同的map和reduction。
7，程序可以非常小，如20到50行代码
8，一个问题是掉队者。掉队者是一个比其他程序慢的计算，它阻塞了其他程序。掉队者可能因为缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的
9，数据在Map和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。
在BigTable里存储结构化数据
1，BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它可以每秒钟处理百万的读写
2，BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询
3，它提供查询机制来通过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据
4，商业数据库不能达到这种级别的伸缩性并且不能在成千上万台机器上工作
5，通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如，如果它们想让跨数据中心的操作更简单这个特性，它们可以内建它
6，系统运行时机器可以自由的增删而整个系统保持工作
7，每个数据条目存储在一个格子里，它可以通过一个行key和列key或者时间戳来访问
8，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列并且格式为SSTable
9，BigTable有三种类型的服务器：
-Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要则重新分配任务
-Tablet服务器为tablet处理读写请求。当tablet超过大小限制(通常是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet然后系统恢复。
-Lock服务器形成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都需要互斥
10，一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的locality选择
11，tablet尽可能的缓存在RAM里
硬件
1，当你有很多机器时你怎样组织它们来使得使用和花费有效？
2，使用非常廉价的硬件
3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.
4，Linux，in-house rack design，PC主板，低端存储
5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues
6，使用一些collocation和Google自己的数据中心
其他
1，迅速更改而不是等待QA
2，库是构建程序的卓越方式
3，一些程序作为服务提供
4，一个基础组织处理程序的版本，这样它们可以发布而不用害怕会破坏什么东西
Google将来的方向
1，支持地理位置分布的集群
2，为所有数据创建一个单独的全局名字空间。当前的数据由集群分离
3，更多和更好的自动化数据迁移和计算
4，解决当使用网络划分来做广阔区域的备份时的一致性问题(例如保持服务即使一个集群离线维护或由于一些损耗问题)
学到的东西
1，基础组织是有竞争性的优势。特别是对Google而言。Google可以很快很廉价的推出新服务，并且伸缩性其他人很难达到。许多公司采取完全不同的方式。许多公司认为基础组织开销太大。Google认为自己是一个系统工程公司，这是一个新的看待软件构建的方式
2，跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。我们不得不承认怎样在一些数据中心之间完整的分布网站是很需要技巧的
3，如果你自己没有时间从零开始重新构建所有这些基础组织你可以看看Hadoop。Hadoop是这里很多同样的主意的一个开源实现
4，平台的一个优点是初级开发人员可以在平台的基础上快速并且放心的创建健全的程序。如果每个项目都需要发明同样的分布式基础组织的轮子，那么你将陷入困境因为知道怎样完成这项工作的人相对较少
5，协同工作不一直是掷骰子。通过让系统中的所有部分一起工作则一个部分的改进将帮助所有的部分。改进文件系统则每个人从中受益而且是透明的。如果每个项目使用不同的文件系统则在整个堆栈中享受不到持续增加的改进
6，构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级
7，创建可进化的基础组织，并行的执行消耗时间的操作并采取较好的方案
8，不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.
9，考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。
2009年5月12日星期二
SQL Server 2008 R2 新特性
消息来源
Capitalize on Hardware Innovation
Increase in the number of logical processors supported from 64 up to 256. This will provide customers with more choices for obtaining single system scalability with high performance.
Optimize Hardware Resources
Dashboard viewpoints provide real-time insight into utilization and policy violations to help identify consolidation opportunities, maximize investments and maintain healthy systems.
Manage Efficiently at Scale
Through new extensions in SQL Server Management Studio, organizations will gain insights into their growing applications and databases and help ensure higher service levels through policies and dashboard viewpoints.
Enhance Collaboration Across Development and IT
Streamline Application Lifecycle Management through integration with Visual Studio. A new project type enables a single unit of management for packaging database schema with application requirements. This ensures higher quality application development while also accelerating deployments, moves, and changes over time.
Improve the Quality of Your Data
Centralized approach to defining, deploying, and managing master data can ensure reporting consistency across systems and deliver faster more accurate results across the enterprise.
Manage User-Generated Analytical Applications
Comprehensive management thru Microsoft SharePoint gives IT the ability to manage and secure all BI assets, thus freeing the original authors to focus on the priorities of the business.
Report with Ease
Decrease time and costs developing reports by giving users the ability to design their own queries, reports and charts through powerful and intuitive authoring and ad hoc reporting capabilities.
Get More Out of Your Data
New support for geospatial visualization can produce new insights and discoveries when geospatial data is combined with corporate data for reporting and analysis.
Build Robust Analytical Applications
With the in-memory analytics add-in for Microsoft Excel 2010, business users can quickly access, analyze and summarize vast amounts of data directly in Excel without the assistance of the IT department.
Consolidate Your Data
New “data mash up” capabilities will simplify time consuming data gathering and consolidation tasks. Integrate data from multiple sources, including corporate databases and external sources, using powerful tools within Microsoft Excel.
Share and Collaborate with Confidence
New collaboration tools make it easy to share analytic applications and reports through Microsoft Office SharePoint, where they are refreshed automatically, maintained, and made accessible to others.
上面的都是官方宣传词,下面这些是DBA们感兴趣的了
1. 对多核CPU的支持加强,从原来的64核增加到了256核,这样可以提高原有系统的性能和增加扩展性.
2. Management Studio的新特性:
2.1 新向导将帮助DBA快速发现环境中的数据库并加入到集中管理;
2.2 DBA可以通过管理的目标服务器或者集中管理服务器的程序执行统一的期望阀值等政策;
2.3 仪表板(DashBoard)将提供实时图像,反映资源利用率和政策符合度,这些将帮助管理员发现系统需要加固的地方,最大化资源利用率及强化系统健康;
2.4 Visual Studio的整合
加强了开发和运维的联系,新增的包类型可以使DBA参与到开发中,并方便部署
3. Master Data Services (MDS)
4. 对Excel2010 sharepoint 2010支持的增强;
5. Reporting Service 2008 R2增强,支持了更丰富的图形.
Capitalize on Hardware Innovation
Increase in the number of logical processors supported from 64 up to 256. This will provide customers with more choices for obtaining single system scalability with high performance.
Optimize Hardware Resources
Dashboard viewpoints provide real-time insight into utilization and policy violations to help identify consolidation opportunities, maximize investments and maintain healthy systems.
Manage Efficiently at Scale
Through new extensions in SQL Server Management Studio, organizations will gain insights into their growing applications and databases and help ensure higher service levels through policies and dashboard viewpoints.
Enhance Collaboration Across Development and IT
Streamline Application Lifecycle Management through integration with Visual Studio. A new project type enables a single unit of management for packaging database schema with application requirements. This ensures higher quality application development while also accelerating deployments, moves, and changes over time.
Improve the Quality of Your Data
Centralized approach to defining, deploying, and managing master data can ensure reporting consistency across systems and deliver faster more accurate results across the enterprise.
Manage User-Generated Analytical Applications
Comprehensive management thru Microsoft SharePoint gives IT the ability to manage and secure all BI assets, thus freeing the original authors to focus on the priorities of the business.
Report with Ease
Decrease time and costs developing reports by giving users the ability to design their own queries, reports and charts through powerful and intuitive authoring and ad hoc reporting capabilities.
Get More Out of Your Data
New support for geospatial visualization can produce new insights and discoveries when geospatial data is combined with corporate data for reporting and analysis.
Build Robust Analytical Applications
With the in-memory analytics add-in for Microsoft Excel 2010, business users can quickly access, analyze and summarize vast amounts of data directly in Excel without the assistance of the IT department.
Consolidate Your Data
New “data mash up” capabilities will simplify time consuming data gathering and consolidation tasks. Integrate data from multiple sources, including corporate databases and external sources, using powerful tools within Microsoft Excel.
Share and Collaborate with Confidence
New collaboration tools make it easy to share analytic applications and reports through Microsoft Office SharePoint, where they are refreshed automatically, maintained, and made accessible to others.
上面的都是官方宣传词,下面这些是DBA们感兴趣的了
1. 对多核CPU的支持加强,从原来的64核增加到了256核,这样可以提高原有系统的性能和增加扩展性.
2. Management Studio的新特性:
2.1 新向导将帮助DBA快速发现环境中的数据库并加入到集中管理;
2.2 DBA可以通过管理的目标服务器或者集中管理服务器的程序执行统一的期望阀值等政策;
2.3 仪表板(DashBoard)将提供实时图像,反映资源利用率和政策符合度,这些将帮助管理员发现系统需要加固的地方,最大化资源利用率及强化系统健康;
2.4 Visual Studio的整合
加强了开发和运维的联系,新增的包类型可以使DBA参与到开发中,并方便部署
3. Master Data Services (MDS)
4. 对Excel2010 sharepoint 2010支持的增强;
5. Reporting Service 2008 R2增强,支持了更丰富的图形.
2009年5月11日星期一
F5助力eBay数据库服务器负载均衡
美国eBay公司是世界上最大的网上交易平台。据统计，每天有涉及几千个分类的几百万件商品在eBay上销售；eBay的年增长率达到50%。但是，和快速增长的业务相比，eBay的IT支撑系统的高可用性还相对滞后，其IT系统重构规划时还确认用户数据库有单点故障(SPOF)。为此，eBay采用了F5公司提供的数据库服务器负载均衡解决方案，不仅使数据库可用性达到99.9%，而且还实现了在线拓展、高安全和高可管理性，从而解决了eBay的用户数据库服务请求的压力，为其进一步的持续高速发展铺平了道路；该方案也为电子商务以及其他公共服务行业类的数据库服务器负载均衡，提供了一个不可多得的成功样板。
需求及挑战
问题还得从eBay的数据库系统说起，eBay拥有30套生产数据库，全部采用Oracle数据库,其中包括12 数据库支持 “live” 项目 (Sun 480/4500)；1 个数据库支持存档项目(Sun 4800)；4个数据库支持客户数据 (Sun 4800)；2 个数据库支持 eBay的反馈系统 (Sun 480)；1个 数据库支持非正常的 “cache” 数据 (Sun 4800)；其他的数据库 (大部分 Sun 480 class)。同时，采用Hitachi SAN 建立存储架构,建立了两个远程备份数据库，并实施实时复制数据到远程数据库实现冗灾，同时每24小时实施针对数据块的数据备份。
因此，通过eBay 数据库读写的比率分析，可以发现，eBay在数据库提供服务时，读和查询的操作达到530亿次，而数据库写和更新的操作达到2亿次。“读和查询”操作与“写和更新”的比率达到265:1。可见查询和数据库读的操作给数据库管理系统带来巨大的压力。而更为严峻的是，eBay年增长率达到50%，这意味着，来自读和查询的操作压力将持续增大，要保证数据库服务的响应能力和效率，稳定性和安全性，eBay 必须采用数据库服务器的负载均衡解决方案。
但是，由于系统庞大，出于投资保护等考虑，Bay 对数据库服务器的负载均衡解决方案的需求有如下几个特点：不改变eBay的数据库体系结构；可用性目标达到99.9%；需承载eBay每年50%的高成长；简单管理等等。这意味着在不对系统大动干戈的同时，却革命性地提高其性能，其挑战不言而喻。
解决方案
针对eBay数据库服务器负载均衡的需求特点，eBay考虑了三种主要解决方案。1） 将数据库垂直分割，划分成多层数据库处理，减轻原来单层数据库处理数据而形成的瓶颈与可用性问题。但问题：这种方案很难部署，而且也没有从根本上解决单点故障问题。2）采用Oracle OPS/RAC机群解决方案。问题：要求给便数据库编程代码，非常难以管理与维护。3）采用F5 与SharePlex 联合解决方案。其优点是：简单管理，不需要改变整个体系结构。
在最初，eBay采用Oracle OPS/RAC解决问题。但是后来经过充分论证和探讨，最终eBay采用了基于F5/SharePlex的解决方案。F5解决方案是应用类似OPS/RAC，但是却相对简单的f5的解决方案，不用改变数据库体系结构，管理和维护简单得多。F5解决方案得主要思路是，通过应用将数据库“读与查询”的操作与”写和更新”的操作导向到分开的 “逻辑” 数据库，这些数据库服务器都单独配备数据存储，而没有采用共享存储的方式！这样，F5 应用交换机动态的将所有的数据库”读与查询”请求导向到查询数据库服务器群中，并智能负载均衡到最佳的数据库服务器上。所有的”写和更新”请求都指向到一个单一的数据库服务器上,由SeharePlex动态实时将数据记录复制到”读与查询”数据库服务器群的数据库中。
这样，一方面，数据库服务器群被F5应用交换机虚拟化和集群，变成了一个“池”；另一方面，“读与查询”的操作，可以根据需要，选择更高效率得数据库服务器，从而使“读与查询”的操作压力得到解决。同时，随着业务的增长，还可以随时根据客户业务的压力在线扩展新的服务器在这个群之中。由于根据以上分析，数据库读写的比例超过260倍，采用这样的方法，有效解决了数据库性能和高可用性要求。
采用F5/Share Plex 解决方案示意图
方案特点
F5解决方案具有以下特点：1.运用分离读和写操作，使读和写操作进入分别的逻辑数据库 而不是共享磁盘2. f5 数据库服务器均衡可以使所有的读操作交叉分配到available hosts; 所有的写操作都指定到单一的database-of-record ; 3.应用类似OPS/RAC，但是却相对简单的f5的解决方案; 4.发挥f5产品灵敏的量测性和显著的增强可用性。
采用F5的BIG-IP负载均衡器后,对于eBay应用系统有独到的优势:
高可用性: BIGIP动态分配每一个流量请求到后台的四台Oracle 9i Database 数据库服务器,并动态检查各个服务器的健康状态,将下一个请求分配给最有效率的服务器,任何服务起死机时,BIGIP即刻将流量请求分配给其他的三台服务器,从而达到99.999%系统有效性。特别是针对Oracle 9i 数据库服务器，F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验(EAV)进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的iCMP / TCP 层进行健康检查。
高安全性: BIGIP支持地址翻译技术和安全地址翻译，这样一来客户不可能知道真正提供服务的服务器的IP地址与端口，从而保护数据库服务器不受到诸如SYN Flood 等DOS及DDOS进攻。
高效率: 采用BIG-IP 负载均衡之后, BIG-IP可以智能寻找最佳状态的数据库服务器从而保证客户得到响应最快的数据库服务器以提供最佳的查询数据库服务!
高可扩展性: BIGIP可以支持动态增加或删除其负载均衡的数据库服务器群组的任何数量的服务器,而不需要对前端或后台做任何改变从而使得系统扩展轻松方便，透明。
高可管理性: BIGIP有专门的管理软件可以实时监控整个数据库服务器群组的流量状态,并分析发展趋势帮助客户及时根据流量增长增加服务器。
客户价值
F5解决方案具有低成本、低维修，以及保护投资，高效率的特点，并方便在线拓展，面向未来。在2001年第二季度，F5公司与Quest公司合作成功帮助客户实现了以上解决方案，初期布署了两台”读与查询”数据库服务器和一台”写和更新”数据库服务器。在2001年第三季度成功通过了99.9%高可用性。并真正实现了在线高可扩展性，在2002年增加另外两台读与查询”数据库服务器，并于2002年第三季度增加部署了冗灾备份的功能。
F5提供的eBay数据库服务器负载均衡解决方案对行业也具有相当的借鉴意义。电子商务应用同样有着数据库查询的压力，如果能够有效将查询的压力分解到单独的服务器群来处理，将有效提高电子商务的应用效率。 对于电子商务类应用系统数据库扩展解决方案，只需要在Web Portal上将数据库请求分成两个不同模块，问题便迎刃而解。
对于公众服务行业类的数据库服务器的负载均衡，如银行，电信，税务等系统，每月和每季度的都会有报表生成汇总，这些报表既包括用户的月结单数据信息，也需要产生总体业务的业绩报告。这样就必须对数据库系统进行检索和查询。如果这些业务工作与实际生产环境是一个数据库的情况下，将造成系统的巨大压力。采用F5类似方法，同样能够有效达到高可用性预告可扩展性能的需要！
需求及挑战
问题还得从eBay的数据库系统说起，eBay拥有30套生产数据库，全部采用Oracle数据库,其中包括12 数据库支持 “live” 项目 (Sun 480/4500)；1 个数据库支持存档项目(Sun 4800)；4个数据库支持客户数据 (Sun 4800)；2 个数据库支持 eBay的反馈系统 (Sun 480)；1个 数据库支持非正常的 “cache” 数据 (Sun 4800)；其他的数据库 (大部分 Sun 480 class)。同时，采用Hitachi SAN 建立存储架构,建立了两个远程备份数据库，并实施实时复制数据到远程数据库实现冗灾，同时每24小时实施针对数据块的数据备份。
因此，通过eBay 数据库读写的比率分析，可以发现，eBay在数据库提供服务时，读和查询的操作达到530亿次，而数据库写和更新的操作达到2亿次。“读和查询”操作与“写和更新”的比率达到265:1。可见查询和数据库读的操作给数据库管理系统带来巨大的压力。而更为严峻的是，eBay年增长率达到50%，这意味着，来自读和查询的操作压力将持续增大，要保证数据库服务的响应能力和效率，稳定性和安全性，eBay 必须采用数据库服务器的负载均衡解决方案。
但是，由于系统庞大，出于投资保护等考虑，Bay 对数据库服务器的负载均衡解决方案的需求有如下几个特点：不改变eBay的数据库体系结构；可用性目标达到99.9%；需承载eBay每年50%的高成长；简单管理等等。这意味着在不对系统大动干戈的同时，却革命性地提高其性能，其挑战不言而喻。
解决方案
针对eBay数据库服务器负载均衡的需求特点，eBay考虑了三种主要解决方案。1） 将数据库垂直分割，划分成多层数据库处理，减轻原来单层数据库处理数据而形成的瓶颈与可用性问题。但问题：这种方案很难部署，而且也没有从根本上解决单点故障问题。2）采用Oracle OPS/RAC机群解决方案。问题：要求给便数据库编程代码，非常难以管理与维护。3）采用F5 与SharePlex 联合解决方案。其优点是：简单管理，不需要改变整个体系结构。
在最初，eBay采用Oracle OPS/RAC解决问题。但是后来经过充分论证和探讨，最终eBay采用了基于F5/SharePlex的解决方案。F5解决方案是应用类似OPS/RAC，但是却相对简单的f5的解决方案，不用改变数据库体系结构，管理和维护简单得多。F5解决方案得主要思路是，通过应用将数据库“读与查询”的操作与”写和更新”的操作导向到分开的 “逻辑” 数据库，这些数据库服务器都单独配备数据存储，而没有采用共享存储的方式！这样，F5 应用交换机动态的将所有的数据库”读与查询”请求导向到查询数据库服务器群中，并智能负载均衡到最佳的数据库服务器上。所有的”写和更新”请求都指向到一个单一的数据库服务器上,由SeharePlex动态实时将数据记录复制到”读与查询”数据库服务器群的数据库中。
这样，一方面，数据库服务器群被F5应用交换机虚拟化和集群，变成了一个“池”；另一方面，“读与查询”的操作，可以根据需要，选择更高效率得数据库服务器，从而使“读与查询”的操作压力得到解决。同时，随着业务的增长，还可以随时根据客户业务的压力在线扩展新的服务器在这个群之中。由于根据以上分析，数据库读写的比例超过260倍，采用这样的方法，有效解决了数据库性能和高可用性要求。
采用F5/Share Plex 解决方案示意图
方案特点
F5解决方案具有以下特点：1.运用分离读和写操作，使读和写操作进入分别的逻辑数据库 而不是共享磁盘2. f5 数据库服务器均衡可以使所有的读操作交叉分配到available hosts; 所有的写操作都指定到单一的database-of-record ; 3.应用类似OPS/RAC，但是却相对简单的f5的解决方案; 4.发挥f5产品灵敏的量测性和显著的增强可用性。
采用F5的BIG-IP负载均衡器后,对于eBay应用系统有独到的优势:
高可用性: BIGIP动态分配每一个流量请求到后台的四台Oracle 9i Database 数据库服务器,并动态检查各个服务器的健康状态,将下一个请求分配给最有效率的服务器,任何服务起死机时,BIGIP即刻将流量请求分配给其他的三台服务器,从而达到99.999%系统有效性。特别是针对Oracle 9i 数据库服务器，F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验(EAV)进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的iCMP / TCP 层进行健康检查。
高安全性: BIGIP支持地址翻译技术和安全地址翻译，这样一来客户不可能知道真正提供服务的服务器的IP地址与端口，从而保护数据库服务器不受到诸如SYN Flood 等DOS及DDOS进攻。
高效率: 采用BIG-IP 负载均衡之后, BIG-IP可以智能寻找最佳状态的数据库服务器从而保证客户得到响应最快的数据库服务器以提供最佳的查询数据库服务!
高可扩展性: BIGIP可以支持动态增加或删除其负载均衡的数据库服务器群组的任何数量的服务器,而不需要对前端或后台做任何改变从而使得系统扩展轻松方便，透明。
高可管理性: BIGIP有专门的管理软件可以实时监控整个数据库服务器群组的流量状态,并分析发展趋势帮助客户及时根据流量增长增加服务器。
客户价值
F5解决方案具有低成本、低维修，以及保护投资，高效率的特点，并方便在线拓展，面向未来。在2001年第二季度，F5公司与Quest公司合作成功帮助客户实现了以上解决方案，初期布署了两台”读与查询”数据库服务器和一台”写和更新”数据库服务器。在2001年第三季度成功通过了99.9%高可用性。并真正实现了在线高可扩展性，在2002年增加另外两台读与查询”数据库服务器，并于2002年第三季度增加部署了冗灾备份的功能。
F5提供的eBay数据库服务器负载均衡解决方案对行业也具有相当的借鉴意义。电子商务应用同样有着数据库查询的压力，如果能够有效将查询的压力分解到单独的服务器群来处理，将有效提高电子商务的应用效率。 对于电子商务类应用系统数据库扩展解决方案，只需要在Web Portal上将数据库请求分成两个不同模块，问题便迎刃而解。
对于公众服务行业类的数据库服务器的负载均衡，如银行，电信，税务等系统，每月和每季度的都会有报表生成汇总，这些报表既包括用户的月结单数据信息，也需要产生总体业务的业绩报告。这样就必须对数据库系统进行检索和查询。如果这些业务工作与实际生产环境是一个数据库的情况下，将造成系统的巨大压力。采用F5类似方法，同样能够有效达到高可用性预告可扩展性能的需要！
2009年5月9日星期六
如何使用SQL SERVER 数据库管理员专用连接（DAC）
使用专用管理员连接
SQL Server 为管理员提供了一种特殊的诊断连接，以供在无法与服务器建立标准连接时使用。即使在 SQL Server 不响应标准连接请求时，管理员也可以使用此诊断连接访问 SQL Server，以便执行诊断查询并解决问题。
此专用管理员连接 (DAC) 支持 SQL Server 的加密功能和其他安全功能。DAC 只允许将用户上下文切换到其他管理用户。
SQL Server 尽力使 DAC 连接成功，但在非常特殊的情况下也可能会出现连接失败。
使用 DAC 连接
默认情况下，只能从服务器上运行的客户端建立连接。不允许进行网络连接，除非它们是使用带 remote admin connections 选项的 sp_configure 存储过程配置的。
只有 SQL Server sysadmin 角色的成员可以使用 DAC 连接。
数据库实例同一时间仅支持一个专用连接。
通过使用专用的管理员开关 (-A) 的 sqlcmd 命令提示实用工具，可以支持和使用 DAC。有关使用 sqlcmd 的详细信息，请参阅将 sqlcmd 与脚本变量结合使用。您还可以将前缀 admin: 连接到实例名上，格式为 sqlcmd -Sadmin:。还可以通过连接到 admin:<实例名>，从 SQL Server Management Studio 查询编辑器启动 DAC。
限制
由于 DAC 仅用于在极少数情况下诊断服务器问题，因此对连接有一些限制：
为了保证有可用的连接资源，每个 SQL Server 实例只允许使用一个 DAC。如果 DAC 连接已经激活，则通过 DAC 进行连接的任何新请求都将被拒绝，并出现错误 17810。
为了保留资源，SQL Server Express 不侦听 DAC 端口，除非使用跟踪标志 7806 进行启动。
DAC 最初尝试连接到与登录帐户关联的默认数据库。连接成功后，可以连接到 master 数据库。如果默认数据库脱机或不可用，则连接返回错误 4060。但是，如果使用以下命令覆盖默认数据库，改为连接到 master 数据库，则连接会成功：
sqlcmd –A –d master
由于只要启动数据库引擎实例，就能保证 master 数据库处于可用状态，因此建议使用 DAC 连接到 master 数据库。
SQL Server 禁止使用 DAC 运行并行查询或命令。例如，如果使用 DAC 执行下列任何语句，都会生成错误 3637。
RESTORE
BACKUP
DAC 只能使用有限的资源。请勿使用 DAC 运行需要消耗大量资源的查询（例如，对大型表执行复杂的联接）或可能造成阻塞的查询。这有助于防止将 DAC 与任何现有的服务器问题混淆。为了避免发生潜在的阻塞情况，如果必须执行可能会发生阻塞的查询，则尽可能在基于快照的隔离级别下运行查询；或者，将事务隔离级别设置为 READ UNCOMMITTED，将 LOCK_TIMEOUT 值设置为较短的值（如 2000 毫秒），或者同时执行这两种操作。这可以防止 DAC 会话被阻塞。但是，根据 SQL Server 所处的状态，DAC 会话可能会在闩锁上被阻塞。可以使用 CNTRL-C 终止 DAC 会话，但不能保证一定成功。如果失败，唯一的选择是重新启动 SQL Server。
为保证连接成功并排除 DAC 故障，SQL Server 保留了一定的资源用于处理 DAC 上运行的命令。通常这些资源只够执行简单的诊断和故障排除功能，如下所示。
虽然理论上可以运行任何不必在 DAC 上并行执行的 Transact-SQL 语句，但极力建议您限制使用下列诊断和故障排除命令：
查询动态管理视图以进行基本的诊断，例如查询 sys.dm_tran_locks 以了解锁定状态，查询 sys.dm_os_memory_cache_counters 以检查缓存质量，查询 sys.dm_exec_requests 和 sys.dm_exec_sessions 以了解活动的会话和请求。避免使用需要消耗大量资源的动态管理视图（例如，sys.dm_tran_version_store 扫描整个版本存储区，并且会导致大量的 I/O）或使用了复杂联接的动态管理视图。有关性能影响的信息，请参阅特定动态管理视图的文档。
查询目录视图。
基本 DBCC 命令，例如 DBCC FREEPROCCACHE、DBCC FREESYSTEMCACHE、DBCC DROPCLEANBUFFERS, 和 DBCC SQLPERF。请勿运行需要消耗大量资源的命令，如 DBCC CHECKDB、DBCC DBREINDEX 或 DBCC SHRINKDATABASE。
Transact-SQL KILL 命令。根据 SQL Server 的状态，KILL 命令并非一定会成功；如果失败，则唯一的选择是重新启动 SQL Server。下面是一般的指导原则：
请通过查询 SELECT * FROM sys.dm_exec_sessions WHERE session_id = 来验证 SPID 是否已被实际终止。如果没有返回任何行，则表明会话已被终止。
如果会话仍在运行，则通过运行查询 SELECT * FROM sys.dm_os_tasks WHERE session_id = 来验证是否为此会话分配了任务。如果发现还有任务，则很可能当前正在终止会话。注意，此操作可能会持续很长时间，也可能根本不会成功。
如果在与此会话关联的 sys.dm_os_tasks 中没有任何任务，但是在执行 KILL 命令后该会话仍然出现在 sys.dm_exec_sessions 中，则表明没有可用的工作线程。选择某个当前正在运行的任务（在 sys.dm_os_tasks 视图中列出的 sessions_id <> NULL 的任务），并终止与其关联的会话以释放工作线程。请注意，终止单个会话可能不够，可能需要终止多个会话。
DAC 端口
SQL Server 在启动数据库引擎时动态分配的专用 TCP/IP 端口上侦听 DAC。错误日志包含所侦听的 DAC 所在的端口号。默认情况下，DAC 侦听器只接受本地端口上的连接。有关激活远程管理员连接的代码示例，请参阅 remote admin connections 选项。
配置远程管理连接之后，会立即启用 DAC 侦听器而不必重新启动 SQL Server，并且客户端可以立即远程连接到 DAC。通过先在本地使用 DAC 连接到 SQL Server，然后再执行 sp_configure 存储过程接受远程连接，则即使 SQL Server 停止响应，DAC 侦听器仍然可以接受远程连接。
对于群集配置，DAC 在默认情况下是禁用的。用户可以执行 sp_configure 的 remote admin connection 选项，使 DAC 侦听器能够访问远程连接。如果 SQL Server 停止响应并且未启用 DAC 侦听器，则可能必须重新启动 SQL Server 来连接 DAC。因此，建议在群集系统上启用 remote admin connections 配置选项。
DAC 端口由 SQL Server 在启动时动态分配。当连接到默认实例时，DAC 会避免在连接时对 SQL Server Browser 服务使用 SQL Server 解决协议 (SSRP) 请求。它先通过 TCP 端口 1434 进行连接。如果失败，则通过 SSRP 调用来获取端口。如果 SQL Server 浏览器没有侦听 SSRP 请求，则连接请求将返回错误。若要了解 DAC 所侦听的端口号，请参阅错误日志。如果将 SQL Server 配置为接受远程管理连接，则必须使用显式端口号启动 DAC：
sqlcmd –Stcp:,
SQL Server 错误日志列出了 DAC 的端口号，默认情况下为 1434。如果将 SQL Server 配置为只接受本地 DAC 连接，请使用以下命令和环回适配器进行连接：
sqlcmd –S127.0.0.1,1434
示例
在此示例中，管理员发现服务器 URAN123 不响应，因此要诊断该问题。为此，用户激活 sqlcmd 命令提示实用工具，并使用 -A 指明 DAC 连接到服务器 URAN123。
sqlcmd -S URAN123 -U sa -P –A
现在，管理员可以执行查询来诊断问题，并且可以终止停止响应的会话。
SQL Server 为管理员提供了一种特殊的诊断连接，以供在无法与服务器建立标准连接时使用。即使在 SQL Server 不响应标准连接请求时，管理员也可以使用此诊断连接访问 SQL Server，以便执行诊断查询并解决问题。
此专用管理员连接 (DAC) 支持 SQL Server 的加密功能和其他安全功能。DAC 只允许将用户上下文切换到其他管理用户。
SQL Server 尽力使 DAC 连接成功，但在非常特殊的情况下也可能会出现连接失败。
使用 DAC 连接
默认情况下，只能从服务器上运行的客户端建立连接。不允许进行网络连接，除非它们是使用带 remote admin connections 选项的 sp_configure 存储过程配置的。
只有 SQL Server sysadmin 角色的成员可以使用 DAC 连接。
数据库实例同一时间仅支持一个专用连接。
通过使用专用的管理员开关 (-A) 的 sqlcmd 命令提示实用工具，可以支持和使用 DAC。有关使用 sqlcmd 的详细信息，请参阅将 sqlcmd 与脚本变量结合使用。您还可以将前缀 admin: 连接到实例名上，格式为 sqlcmd -Sadmin:
限制
由于 DAC 仅用于在极少数情况下诊断服务器问题，因此对连接有一些限制：
为了保证有可用的连接资源，每个 SQL Server 实例只允许使用一个 DAC。如果 DAC 连接已经激活，则通过 DAC 进行连接的任何新请求都将被拒绝，并出现错误 17810。
为了保留资源，SQL Server Express 不侦听 DAC 端口，除非使用跟踪标志 7806 进行启动。
DAC 最初尝试连接到与登录帐户关联的默认数据库。连接成功后，可以连接到 master 数据库。如果默认数据库脱机或不可用，则连接返回错误 4060。但是，如果使用以下命令覆盖默认数据库，改为连接到 master 数据库，则连接会成功：
sqlcmd –A –d master
由于只要启动数据库引擎实例，就能保证 master 数据库处于可用状态，因此建议使用 DAC 连接到 master 数据库。
SQL Server 禁止使用 DAC 运行并行查询或命令。例如，如果使用 DAC 执行下列任何语句，都会生成错误 3637。
RESTORE
BACKUP
DAC 只能使用有限的资源。请勿使用 DAC 运行需要消耗大量资源的查询（例如，对大型表执行复杂的联接）或可能造成阻塞的查询。这有助于防止将 DAC 与任何现有的服务器问题混淆。为了避免发生潜在的阻塞情况，如果必须执行可能会发生阻塞的查询，则尽可能在基于快照的隔离级别下运行查询；或者，将事务隔离级别设置为 READ UNCOMMITTED，将 LOCK_TIMEOUT 值设置为较短的值（如 2000 毫秒），或者同时执行这两种操作。这可以防止 DAC 会话被阻塞。但是，根据 SQL Server 所处的状态，DAC 会话可能会在闩锁上被阻塞。可以使用 CNTRL-C 终止 DAC 会话，但不能保证一定成功。如果失败，唯一的选择是重新启动 SQL Server。
为保证连接成功并排除 DAC 故障，SQL Server 保留了一定的资源用于处理 DAC 上运行的命令。通常这些资源只够执行简单的诊断和故障排除功能，如下所示。
虽然理论上可以运行任何不必在 DAC 上并行执行的 Transact-SQL 语句，但极力建议您限制使用下列诊断和故障排除命令：
查询动态管理视图以进行基本的诊断，例如查询 sys.dm_tran_locks 以了解锁定状态，查询 sys.dm_os_memory_cache_counters 以检查缓存质量，查询 sys.dm_exec_requests 和 sys.dm_exec_sessions 以了解活动的会话和请求。避免使用需要消耗大量资源的动态管理视图（例如，sys.dm_tran_version_store 扫描整个版本存储区，并且会导致大量的 I/O）或使用了复杂联接的动态管理视图。有关性能影响的信息，请参阅特定动态管理视图的文档。
查询目录视图。
基本 DBCC 命令，例如 DBCC FREEPROCCACHE、DBCC FREESYSTEMCACHE、DBCC DROPCLEANBUFFERS, 和 DBCC SQLPERF。请勿运行需要消耗大量资源的命令，如 DBCC CHECKDB、DBCC DBREINDEX 或 DBCC SHRINKDATABASE。
Transact-SQL KILL
请通过查询 SELECT * FROM sys.dm_exec_sessions WHERE session_id =
如果会话仍在运行，则通过运行查询 SELECT * FROM sys.dm_os_tasks WHERE session_id =
如果在与此会话关联的 sys.dm_os_tasks 中没有任何任务，但是在执行 KILL 命令后该会话仍然出现在 sys.dm_exec_sessions 中，则表明没有可用的工作线程。选择某个当前正在运行的任务（在 sys.dm_os_tasks 视图中列出的 sessions_id <> NULL 的任务），并终止与其关联的会话以释放工作线程。请注意，终止单个会话可能不够，可能需要终止多个会话。
DAC 端口
SQL Server 在启动数据库引擎时动态分配的专用 TCP/IP 端口上侦听 DAC。错误日志包含所侦听的 DAC 所在的端口号。默认情况下，DAC 侦听器只接受本地端口上的连接。有关激活远程管理员连接的代码示例，请参阅 remote admin connections 选项。
配置远程管理连接之后，会立即启用 DAC 侦听器而不必重新启动 SQL Server，并且客户端可以立即远程连接到 DAC。通过先在本地使用 DAC 连接到 SQL Server，然后再执行 sp_configure 存储过程接受远程连接，则即使 SQL Server 停止响应，DAC 侦听器仍然可以接受远程连接。
对于群集配置，DAC 在默认情况下是禁用的。用户可以执行 sp_configure 的 remote admin connection 选项，使 DAC 侦听器能够访问远程连接。如果 SQL Server 停止响应并且未启用 DAC 侦听器，则可能必须重新启动 SQL Server 来连接 DAC。因此，建议在群集系统上启用 remote admin connections 配置选项。
DAC 端口由 SQL Server 在启动时动态分配。当连接到默认实例时，DAC 会避免在连接时对 SQL Server Browser 服务使用 SQL Server 解决协议 (SSRP) 请求。它先通过 TCP 端口 1434 进行连接。如果失败，则通过 SSRP 调用来获取端口。如果 SQL Server 浏览器没有侦听 SSRP 请求，则连接请求将返回错误。若要了解 DAC 所侦听的端口号，请参阅错误日志。如果将 SQL Server 配置为接受远程管理连接，则必须使用显式端口号启动 DAC：
sqlcmd –Stcp:
SQL Server 错误日志列出了 DAC 的端口号，默认情况下为 1434。如果将 SQL Server 配置为只接受本地 DAC 连接，请使用以下命令和环回适配器进行连接：
sqlcmd –S127.0.0.1,1434
示例
在此示例中，管理员发现服务器 URAN123 不响应，因此要诊断该问题。为此，用户激活 sqlcmd 命令提示实用工具，并使用 -A 指明 DAC 连接到服务器 URAN123。
sqlcmd -S URAN123 -U sa -P
现在，管理员可以执行查询来诊断问题，并且可以终止停止响应的会话。
2009年5月7日星期四
用标准纸张打印大图片ProPoster
ProPoster是一款将大幅图片分割打印的实用软件，该软件无需特别打印机的支持，它可以在普通的标准打印机上打印大尺寸横幅，签名，海报等。图片，数码照片，Microsoft Word 文档，Excel 电子数据表格都可以被作为海报的来源，也可以直接采集扫描仪的数据。
使用ProPoster，简单地选择一个图像，该软件就会自动地将其分割为必要数量的页面，然后将各页面打印出来，再加工就能完成大幅图片的打印工作，为您节省不少费用。
软件原版为多国语言，但仅支持繁体中文
使用ProPoster，简单地选择一个图像，该软件就会自动地将其分割为必要数量的页面，然后将各页面打印出来，再加工就能完成大幅图片的打印工作，为您节省不少费用。
软件原版为多国语言，但仅支持繁体中文
订阅：
博文 (Atom)
博文
