本实例要说明的是在登录系统后如何自动运行应该程序，如windows下自动行动QQ等。
本实例的内容是：登录系统后，自动运行EVA应用程序。
其实这个实例相当的简单，只要了解系统登录后，它需要执行哪些脚本文件。那系统登录后运行了哪几个脚本呢？
答案是:root目录下面的.bash_profile和bashrc等脚本文件，而bash_profile是第一个执行的。所以，只要在此脚本下添加以下语句即可实现：
[root@localhost ~]# vim ~/.bash_profile
添加内容为：
export DISPLAY=:0 &&eva &
保存并退出。
最后，重启系统即可实现。
IPv6隧道是将IPv6报文封装在IPv4报文中，让IPv6数据包穿过IPv4网络进行通信。对于采用隧道技术的设备来说，在隧道的入口处，将IPv6的数据报封装进IPv4，IPv4报文的源地址和目的地址分别是隧道入口和隧道出口的IPv4地址;在隧道的出口处，再将IPv6报文取出转发到目的节点。隧道技术只要求在隧道的入口和出口处进行修改，对其他部分没有要求，容易实现。但是，隧道技术不能实现IPv4主机与IPv6主机的直接通信。
配置隧道和自动隧道的主要区别在于：只有执行隧道功能的节点的IPv6地址是IPv4兼容地址时，自动隧道才是可行的。在为执行隧道功能的节点建立I P地址时，自动隧道方法无需进行配置;而配置隧道方法则要求隧道末端节点使用其他机制来获得其IPv4地址，例如采用D H C P、人工配置或其他IPv4的配置机制。
如果大家在用笔记本，经常调试网络的话。Windows7会自发建立一条IPV6隧道，通常我们用ipconfig /all就会看到很多条隧道，比如我这边有40多个隧道，想看IPv4信息的话，就会一闪而过，给使用带来不便。这是因为Windows7在IPv6迁移过程中需要使用一种或多种IPv6过渡技术。我们可以通过手动关闭IPv6隧道。
我们只用使用以下3条命令把IPv6的接口关闭即可
netsh interface teredo set state disable
netsh interface 6to4 set state disabled
netsh interface isatap set state disabled
若想还原IPv6隧道则用以下命令:
netsh interface teredo set state default
netsh interface 6to4 set state default
netsh interface isatap set state default
通常来说，Windows中默认的文件格式是GBK(gb2312)，而Linux一般都是UTF-8，所以Linux下打开windows的文件会有乱码的情况。另外，有时要将文件进行编码转换，如将简体中文转换为繁体中文。
基于以上情况，本文将就在linux下查看和转换文件的编码进行说明。
1.查看文件的编码
1)在Vim中可以直接查看文件编码
:set fileencoding 即可显示文件编码格式。
2)enca查看文件编码
# enca filename 直接用enca加文件名查看
# enca -L zh_CN filename
注：enca对某些GBK编码的文件识别不是很好，识别时会出现：unrecognized encoding.
2.转换文件的编码
1)在Vim中直接进行转换文件编码,比如将一个文件转换成utf-8格式
:set fileencoding=utf-8
2)enconv 转换文件编码，比如要将一个GBK编码的文件转换成UTF-8编码，如：
# enconv -L zh_CN -x UTF-8 filename
# enca -L zh_CN -x UTF-8 file2 不覆盖原文件
3)iconv 转换，iconv的命令格式如下：
# iconv -f encoding -t encoding inputfile
# iconv -l 查询可用编码
# for i in `find ./ -name *.html`;do echo $i;iconv -f gb2312 -t big5 $i -o /tmp/iconv.tmp;mv /tmp/iconv.tmp $i;done
批量转换文件编码实例之一
3.文件名编码转换
Linux与windows间拷贝文件，有时文件名会出现乱码，是因为Windows的文件名中文编码默认为GBK，而Linux默认的文件名为UTF8。在Linux中有个工具，convmv，可以对文件名进行GBK和UTF的相互转换。
Linux进程监控方法和工具都是基于调用操作系统给我们提供的相应的API接口函数或者系统调用来实现的。我们所得到的只是接口函数处理后的结果，不能够主动地从操作系统内核的进程数据结构当中获取我们需要的信息。
因而，它们具有如下一些问题：
1、传统的进程监控方法运行效率比较低，同时反应时间也比较长，实时性能差。
2、不能够实时、高效地向用户报告当前系统运行的安全状况，就算系统中有不法进程在运行，系统也不能识别出来。
3、不能给用户捕捉不法进程的行为提供证据和进程的活动轨迹。当一个不法进程运行并对系统产生破坏时，用户即使通过察看进程列表找到了不合法的进程，也不清楚到底从进程开始运行直到捕捉到这样一个不法进程这样一段时间内，进程都对系统造成了哪些破坏，比如说，访问、修改了哪些重要的系统文件，占用了哪些系统资源等等。这些都给以后的恢复和处理工作带来了很大的问题。
4、执行程序工作在用户态，本身就不安全，入侵系统的黑客可以轻松地找到这些进程监控程序的磁盘映像，进行删除甚至替换，从而会给系统带来不可估量的损失。这一点尤其需要强调，比如说，黑客入侵系统成功，就可以植入他们所改写的ps程序以替换原来系统的ps程序，这样就使得用户不能通过该工具得知系统中当前运行的不法进程，这样无论黑客如何植入木马或者其他程序，用户都无法知道，从而无法采取措施终止这些行为。不言而喻，这样的后果是很严重的。而在我们下面所要介绍的一种运行于内核的进程监控程序当中，黑客根本无法或者很难深入内核来破坏该进程监控程序，从而使其能够很好地保证自身的安全。
基于上述种种不足，我们提出了在Linux内核中实现进程实时监控的原理和技术。该技术主要分为以下几个步骤：
首先，在“干净”的系统环境下，全面地运行系统中的安全进程，分析和搜集Linux环境下这些进程的相关信息(包括进程ID号、进程名称、进程可执行映像、进程的开始时间、进程的父进程等主要信息)，形成一张“系统安全进程列表”，作为进程监控的依据。
接着，监控代码在进程调度过程中实时地搜集系统中运行进程的信息。如果发现进程不在 “系统安全进程列表”当中，则马上通过终端输出该进程的PID号、名称、进程的可执行映像等信息，或者通过声音向用户报警，等待用户处理，在这个等待的过程中，终止调度该进程，直到用户做出响应(放行该进程或者杀死该进程)。
在第二步当中，如果超级用户(系统管理员)放行了该进程，则可以将该进程加入“系统安全进程列表”，以完善该列表;如果是一般用户在使用过程当中放行了某个进程，那么，需要将该用户的用户名和身份记录下来，并且将放行的进程记录下来存为日志，那么，当超级用户(系统管理员)无论是在审核用户行为还是在修改“系统安全进程列表”时，都是一个有力的依据。
另外，在系统运行过程当中，如果发现“系统安全进程列表”当中的某些重要的进程 (包括kswapd、bdflush等)不在运行，则马上将该进程“遗失”的信息存入文件，以备在系统的恢复过程当中，对它们进行针对性的恢复，根据不同的情况，有的需要马上停机，恢复进程，有的则可以现场恢复。
你是否经常会听到人们把 Linux 及 BSD 系统混为一谈？是的，我有时会经常听到一些新手，甚至于媒体都这么说。当然，事实上这两者确实有很多相似之处，比如它们都是基于 Unix 演变而来，而且基本上这两类系统都是由非盈利组织及团队开发，另外我更想说的是，这两个系统都有一个共同的目标–那就是创建最有用、最可靠的操作系统。
不过话说回来，这两个系统确实存在着明显的差异，当人们忽略这点的时候，整个 BSD 社区都会感到异常的愤怒，因此我们也可以经常看到 BSD 社区人员或 BSD 用户会对 Linux 不屑一顾。因此，我会尽我所能来帮助我的 BSD 的弟兄们，让更多的人了解到 Linux 与 BSD 的不同之处在哪里。
1、许可证
正如我们所知道的，Linux 操作系统是基于 GPL 许可证授权下的。该许可证可防止开源软件被转换为封闭源代码软件及确保源代码的可用性。 GPL 许可证的目的就是防止二进制包成为唯一的软件发行源。
而 BSD 许可证的限制则要少得多，它甚至允许二进制包成为唯一的发行源。这就是核心差异，可以这样理解：GPL 许可证让您有权拥有任何你想要使用该软件的方法，但你必须确保提供源代码给下一个使用它的人（包括你对它的改变部分）。而 BSD 许可证并不是要求你必须那么做。
2、代码控制
BSD 的代码不是被控制在任何一个人手里，而 Linux 的内核基本上被 Linus Torvalds ( Linux 创始人 ) 所控制，BSD 并没有单一的人来说什么可以或什么不可以进入代码。相反，BSD 通过一个核心小组 ” Core Team” 来管理该项目，这个核心小组比非核心小组有更多的发言权来指导 BSD 社区的发展方向，（译者注：而据我所知，FreeBSDD 核心小组的成员会每两年选举一次。）
3、内核 vs 操作系统
BSD 项目维护的是整个操作系统，而 Linux 则只是主要集中在单一的内核上面。这点确实是需要注意的，虽然这两个系统上都运行着许多相同的软件。
4、UNIX-Like
这里有一个关于 BSD vs Linux 的古老说法：” BSD is what you get when a bunch of UNIX hackers sit down to try to port a UNIX system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a UNIX system for the PC “，这里表达了很多。你会发现 BSD 系统更为类似于 UNIX ，而事实上它就是传统 UNIX 的直接衍生品。而 Linux ，则是一个松散的基于 UNIX 衍生品 ( Minix ) 而新创建的一个 OS 。
5、基本系统
这是一个关于 BSD 与 Linux 之间差异的至关重要的理念。 Linux 的”基本系统” 是并不真正存在的，许多人会说，Linux 的基本系统就是内核，但问题是如果没有任何可用的应用程序的话，那么这个内核是完全没有价值的。而另一方面，BSD 则有一个包括众多工具的基本系统， 甚至 libc 也是基本系统的一部分。因为这些组件都被作为一个基本系统，所以它们都是被一起开发和打包的，许多事实表明这样更能创建出一个更具凝聚力的整体。
6、更多来自于源代码
由于 BSD 的开发方式（使用 Ports 系统 ) 的关系，所以用户们更多的是从源代码来安装程序，而不是预先编译好的二进制包。这是一个优势还是劣势？这取决于不同的用户。如果你更多的想从友好或易用性方面考虑的话，看到这一点后你也许会有放弃的念头，对于新用户更是如此。但一些新的用户也有想要从源代码编译安装，这可能比较累人。但是，从源码安装也有一定的优势，比如（库版本控制，通过特殊的包来构建系统等等）。
7、升级
由于 BSD 的开发方式的原因（见第5项），你可以利用一条指令就可以升级你的基本系统到最新版本 （ Freebsd 下是用 freebsd-update fetch update 命令）。或者你也可以下载整个源代码树，然后通过编译来升级。而在 Linux 中，你也可以通过内置的包管理系统来升级系统。前者 (BSD) 仅更新基本系统，而后者 ( Linux ) 则会升级整个系统。不过请记住，BSD 中升级到最新的基本系统并不意味着所有的附加软件包也将会被更新，而 Linux 升级的时候，所有的软件包都会被升级。这是否意味着 Linux 处理得更好吗？在我看未必。我经常会看到 Linux 在升级时出现严重错误，从而需要重新安装整个系统，但这个现象基本不太可能发生在 BSD 的升级过程中。
8、前沿技术
基本上你不太可能会看到 BSD 系统运行着任何非常前沿版本的软件。而在 Linux 这一方面，大量的发行版会分发前沿版本的软件包。如果你是一个 ” If it isn’t broken, don’t fix it” 这样观点的持有者的话，你将会是 BSD 的超级粉丝。但是，如果你很新潮，想要体验一切最新的东西，那么你最好尽快迁移到 Linux 。
9、硬件支持
你会发现，通常情况下 Linux 的硬件支持要比 BSD 更早一些。但这并不是说 BSD 没有像 Linux 那样支持足够多的硬件，它只是意味着在某些情况下 Linux 会在 BSD 之前先支持某些硬件。因此，如果你想要最新的、最好的显卡的话，基本上不用考虑 BSD 了。如果你有一个包含了最新无线芯片的新型笔记本的话，建议你选择 Linux，运气好的话也许它会支持。
10、用户群
在这里我冒险概括一下计算机用户们，但我想先声明一下每一个事物都有例外。下面我要向你展示我对用户分布方面的概括。
Mac –> Windows –> Linux –> BSD –> UNIX
从左边到右边，分别是”使用该 OS 的人里精通电脑的用户群最少”到”使用该 OS 的人里精通电脑的用户群最多”的过渡。我们可以看到，Linux的被放置在了中间，而 BSD 则更接近于右边。许多人会对此有争论，也有些人可能会感觉被冒犯了。但是，个人认为这是一个对”哪些用户使用哪些系统”相当准确的概括。
其他的不同点？
这个列表并不想表明哪个系统比哪个更好。事实上，BSD 和 Linux 各有着自己的亮点。你认为怎么样？有兴趣的话也请表达出你的观点。
本文转载自：http://wowubuntu.com/linux_vs_bsd.html
英文原文：http://blogs.techrepublic.com.com/10things/?p=1709
如果两个用户进程分别锁定了不同的资源，接着又试图锁定对方所锁定的资源，就会产生死锁。此时，SQL Server将自动地选择并中止其中一个进程以解除死锁，使得另外一个进程能够继续处理。系统将回退被中止的事务，并向被回退事务的用户发送错误信息。
大多数设计良好的应用都会在接收到这个错误信息之后重新提交该事务，此时提交成功的可能性是很大的。但是，如果服务器上经常出现这种情况，就会显著地降低服务器性能。为避免死锁，设计应用应当遵循一定的原则，包括：
▲ 让应用每次都以相同的次序访问服务器资源。
▲ 在事务期间禁止任何用户输入。应当在事务开始之前收集用户输入。
▲ 尽量保持事务的短小和简单。
▲ 如合适的话，为运行事务的用户连接指定尽可能低的隔离级别。[适用于6.5，7.0，2000]
此外，对于SQL Server的死锁问题，下面是几则实践中很有用的小技巧。
■ 使用SQL Server Profiler的Create Trace Wizard运行“Identify The Cause of a Deadlock”跟踪来辅助识别死锁问题，它将提供帮助查找数据库产生死锁原因的原始数据。[适用于7.0，2000]
■ 如果无法消除应用中的所有死锁，请确保提供了这样一种程序逻辑：它能够在死锁出现并中止用户事务之后，以随机的时间间隔自动重新提交事务。这里等待时间的随机性非常重要，这是因为另一个竞争的事务也可能在等待，我们不应该让两个竞争的事务等待同样的时间，然后再在同一时间执行它们，这样的话将导致新的死锁。[适用于6.5，7.0，2000]
■ 尽可能地简化所有T-SQL事务。此举将减少各种类型的锁的数量，有助于提高SQL Server应用的整体性能。如果可能的话，应将较复杂的事务分割成多个较简单的事务。[适用于6.5，7.0，2000]
■ 所有条件逻辑、变量赋值以及其他相关的预备设置操作应当在事务之外完成，而不应该放到事务之内。永远不要为了接受用户输入而暂停某个事务，用户输入应当总是在事务之外完成。[适用于6.5，7.0，2000]
■ 在存储过程内封装所有事务，包括BEGIN TRANSACTION和COMMIT TRANSACTION语句。此举从两个方面帮助减少阻塞的锁。首先，它限制了事务运行时客户程序和SQL Server之间的通信，从而使得两者之间的任何消息只能出现于非事务运行时间(减少了事务运行的时间)。其次，由于存储过程强制它所启动的事务或者完成、或者中止，从而防止了用户留下未完成的事务(留下未撤销的锁)。[适用于6.5，7.0，2000]
■ 如果客户程序需要先用一定的时间检查数据，然后可能更新数据，也可能不更新数据，那么最好不要在整个记录检查期间都锁定记录。假设大部分时间都是检查数据而不是更新数据，那么处理这种特殊情况的一种方法就是：先选择出记录(不加UPDATE子句。UPDATE子句将在记录上加上共享锁)，然后把它发送给客户。
如果用户只查看记录但从来不更新它，程序可以什么也不做;反过来，如果用户决定更新某个记录，那么他可以通过一个WHERE子句检查当前的数据是否和以前提取的数据相同，然后执行UPDATE。
类似地，我们还可以检查记录中的时间标识列(如果它存在的话)。如果数据相同，则执行UPDATE操作;如果记录已经改变，则应用应该提示用户以便用户决定如何处理。虽然这种方法需要编写更多的代码，但它能够减少加锁时间和次数，提高应用的整体性能。[适用于6.5，7.0，2000]
■ 尽可能地为用户连接指定具有最少限制的事务隔离级别，而不是总是使用默认的READ COMMITTED。为了避免由此产生任何其他问题，应当参考不同隔离级别将产生的效果，仔细地分析事务的特性。[适用于6.5，7.0，2000]
■ 使用游标会降低并发性。为避免这一点，如果可以使用只读的游标则应该使用READ_ONLY游标选项，否则如果需要进行更新，尝试使用OPTIMISTIC游标选项以减少加锁。设法避免使用SCROLL_LOCKS游标选项，该选项会增加由于记录锁定引起的问题。[适用于6.5，7.0，2000]
■ 如果用户抱怨说他们不得不等待系统完成事务，则应当检查服务器上的资源锁定是否是导致该问题的原因。进行此类检查时可以使用SQL Server Locks Object: Average Wait Time (ms)，用该计数器来度量各种锁的平均等待时间。
如果可以确定一种或几种类型的锁导致了事务延迟，就可以进一步探究是否可以确定具体是哪个事务产生了这种锁。Profiler是进行这类具体分析的最好工具。[适用于7.0，2000]
■ 使用sp_who和sp_who2(SQL Server Books Online没有关于sp_who2的说明，但sp_who2提供了比sp_who更详细的信息)来确定可能是哪些用户阻塞了其他用户。[适用于6.5，7.0，2000]
■ 试试下面的一个或多个有助于避免阻塞锁的建议：1)对于频繁使用的表使用集簇化的索引;2)设法避免一次性影响大量记录的T-SQL语句，特别是INSERT和UPDATE语句;3)设法让UPDATE和DELETE语句使用索引;4)使用嵌套事务时，避免提交和回退冲突。[适用于6.5，7.0，2000]
文件系统自身的机制，导致每台计算机都会遭遇文件碎片的问题，服务器必须的系统与文件共享功能遭遇众多用户访问，导致文件碎片问题尤为严重，最常见的后果是网络速度缓慢、开机时间长以及病毒扫瞄时间特别长等。现时火热流行的技术虚拟化和固态硬盘能不能有效解决由于碎片对存储系统服务器性能的影响呢?
文件碎片对虚拟化影响有许多企业已经开始利用虚拟化的优势来进行服务器整合及数据中心碳排放量的降低。但这种着眼未来的技术所具备的优势还不止如此，虚拟化性能所面临的关键性挑战在于——文件碎片的处理。
文件碎片是存在于非虚拟化环境中且多年来一直悬而未决的一大性能挑战。但虚拟化所带来的碎片问题更加严峻，所需的解决方案也是前所未有的。虚拟机能够利用硬盘分区，让整个磁盘系统看起来都能为虚拟机所用。但是在虚拟化层下，硬件经常要存储系统所产生的文件，要利用整个硬盘所有分区的磁盘存储系统和碎片文件。
虚拟机都有自己的通过主机系统传递的输入/输出请求。因此每个文件请求都会产生很多输入/输出请求——从最低程度上说客户机系统会产生一个请求，然后主机系统再产生一个请求。但是在常规的粉碎环节，尤其是在虚拟机磁盘活动频繁的时候，文件将被粉碎为成百上千个文件碎片。可想而知每个请求的文件和文件的每个碎片所产生的若干输入/输出请求会演变成多么狂乱的行动。对性能的影响将会多么可怕!
对于虚拟机而言，常规的磁盘碎片整理程序是很关键的，这就要利用磁盘碎片技术。基础性的磁盘碎片整理程序，甚至是预设定的磁盘碎片整理程序无法跟上虚拟化的粉碎速度。最可行的也是目前唯一能够提供的解决方案就是持续性后台粉碎解决方案。这种解决方案能够处理那些后台运行的或者闲置的资源;这样是对磁盘碎片整理程序性能有非常积极的作用，性能也总能达到最大化。
存储碎片简单搞定
固态硬盘有着对于传统硬盘的独到优势，但最近的一次来自国外媒体网站的测试结果或许会导致英特尔著名的X25-M固态硬盘失去一些吸引力。一项来自PCPerspective网站的最新测试结果表明，英特尔的损耗均衡(wear-levelling)特性可能会导致大规模的磁盘碎片问题，更为严重的是这些问题几乎无法修复。看起来英特尔的X25-M固态硬盘产品似乎出了一些问题。
这个名叫PCPerspective的网站已经公布了一篇非常详细的固态硬盘长期性能测试报告，在测试过程中，测试人员发现某些在常规硬盘上的取得良好效果的技术在固态硬盘上却并不适用，文章列举了扇区重新映射以及损耗均衡运算法则这两个典型的例子，这二者在常规硬盘上的作用在于加速固态硬盘性能以及延长硬盘的使用寿命，但测试表明这两种技术在固态硬盘出现碎片之后却在很大程度上削弱了固态硬盘的性能表现。更为糟糕的是常规的磁盘碎片整理软件不仅不能解决这一问题反而还会加重情况的恶化，考虑到这种磁盘碎片产生在文件系统层面之上，因此英特尔也有固态硬盘工程师建议用户不要用任何磁盘碎片整理软件来对固态硬盘驱动器进行任何操作。目前唯一能够重新理清驱动器扇叶映射的做法是重新清空整个磁盘。
从Windows Server 2003 SP1开始，客户端便可以通过服务器身份验证安全套接字层（SSL）证书连接到远程桌面服务器。要实现这一功能，只需管理员使用和配置服务器操作系统的“远程桌面会话主机” 配置工具即可。尽管Windows Vista和Windows 7这样的客户端操作系统并无这样的管理工具可用，但服务器仍可以向它们颁发远程桌面连接证书。要通过证书来实现安全的远程桌面连接连接有两种常用配置方法。第一种方法使用组策略和证书模板来进行配置；第二种方法则是使用WMI脚本来进行配置。
第一种方法：使用组策略和证书模板
此种方式允许管理员为域中的多台计算机安装远程桌面证书，前提是域中必须有正常工作的公钥基础结构（PKI）。
首先，管理员需要创建一个远程桌面证书模板。
创建远程桌面证书模板：
- 在企业证书颁发机构中找到“证书模板”。
- 找到并右键单击“计算机”模板，选择“复制模板”。
- 在弹出的对话框中选择“Windows Server 2008 Enterprise”模板类型。
- 要创建“远程桌面身份认证”策略必须先删除“客户端身份验证”和“服务器身份验证”策略，然后再点击“添加”。
- 此时会出现一个“添加应用程序策略扩展”对话框。我们在对话框中单击“新建”。
- 在“添加应用程序策略”对话框中选中“Remote Desktop Authentication”点击“确定”。
- 现在“编辑应用程序策略扩展”对话框显示如下：
- 再通过点击2次确定后，就回到新模板的“属性”对话框了。
此时，新模板的准备工作已经完成。
下一步骤就是发布模板。
发布“RemoteDesktopComputer”证书模板：
- 在企业根证书颁发机构中找到“证书模板”。
- 在“证书模板”上右键单击并选择“新建”—“要颁发的证书模板”。
- 此时会弹出一个“启用证书模板”对话框。我们找到并选择“RemoteDesktopComputer”，然后单击确定。
现在“RemoteDesktopComputer”模板已经发布并可以用于证书请求。
最后一步，我们需要使用组策略将“RemoteDesktopComputer”模板配置为远程桌面身份验证的基本证书。
配置组策略
- 在域控制器上打开“组策略管理”工具，右键单击“默认域策略”并点击“编辑”。此时会弹出“组策略管理编辑器”（注意：策略可以应用到域中的所有计算机，管理员也可以根据需要将其应用到所需的OU）
- 导航至“计算机配置—策略—管理模板—Windows 组件—远程桌面服务—远程桌面会话主机—安全。”
- 双击“服务器身份验证证书模板”策略
- 启用策略，并在“证书模板名称”中输入“RemoteDesktopComputer”并点击确定。
- 当此策略应用到域中的所有计算机后，所有启用远程桌面连接的计算机都将到证书颁发机构服务器去请求基于“RemoteDesktopComputer”模板的证书，并用证书对远程桌面客户端进行验证。（管理员可通过gpupdate /force命令在客户端上强制刷新以获取到组策略的更新）
第二种方法：使用WMI脚本
此方法允许管理员直接使用远程桌面连接的服务器证书，但管理员需要提前手动对证书进行安装。这种方法通常用于：使用企业向Internet公共证书颁发机构购买的证书。
首先需要检查我们已有的证书是否符合远程桌面证书的要求。不符合这些要求的证书将不能正常工作，并将被服务器忽略。
远程桌面证书的基本要求：
- 证书必须安装到计算机的“个人”证书存储区域中
- 必须拥有证书的私钥
- 证书的“增强型密钥用法”扩展中应有“服务器身份验证”或“远程桌面身份验证”（1.3.6.1.4.1.311.54.1.2）。
- 为了正常使用，我们首先要获取到远程桌面连接证书的指纹。
获取证书的指纹：
- 双击已有的证书
- 单击“详细信息”标签
- 在列表中选择“指纹”
- 将指纹值复制到记事本当中
- 删除数字之间的所有空格
如上图示例，我们获取到的指纹应该是： 3d710cecbb29d5dfcb61a6157cefd746b7b04b74
注意：当我们获取到证书指纹之后，才能通过脚本将证书应用于远程桌面连接。.
配置远程桌面证书的WMI脚本：
/* ==============================================================
JScript Source File
NAME: ConfigRemoteDesktop.js
AUTHOR: Billy Fu
DATE : 2010/8/2
==================================================================*/
var strComputer = ".";
var strNamespace = "\\root\\CIMV2\\TerminalServices";
var wbemChangeFlagUpdateOnly = 1;
var wbemAuthenticationLevelPktPrivacy = 6;
var Locator = new ActiveXObject("WbemScripting.SWbemLocator");
Locator.Security_.AuthenticationLevel = wbemAuthenticationLevelPktPrivacy;
var Service = Locator.ConnectServer (strComputer, strNamespace);
var TSSettings = Service.Get("Win32_TSGeneralSetting.TerminalName=\"RDP-Tcp\"");
if (WScript.Arguments.length >= 1 )
{
TSSettings.SSLCertificateSHA1Hash = WScript.Arguments(0);
}
else
{
TSSettings.SSLCertificateSHA1Hash = "0000000000000000000000000000000000000000";
}
TSSettings.Put_(wbemChangeFlagUpdateOnly);
将以上脚本内容复制到 “ConfigRemoteDesktop.js”文件当中，并以管理员方式启动命令提示符号（Cmd.exe.），再通过“cscript ConfigRemoteDesktop.js <证书指纹>”命令来将证书应用到远程桌面连接。
（注意：执行此脚本不加任何参数时将自动还原到远程桌面的自签名证书）
关于作者：付林，TechTarget中国特约专家。2006-2010年微软最有价值专家、获得MCSE、MCSA、MCDBA、MCTS认证。在服务器管理、IT咨询与项目服务领域有多年经验。自由撰稿人，著有《Windows 7来了——Windows 7使用指南》等书籍。
默认的 32 对于低端磁盘子系统已足够。对于附加到可进行高速磁盘 I/O 传输的数据库服务器的高端 RAID(廉价冗余磁盘阵列)存储子系统，选择 32 可能会对 RAID 子系统造成影响，因为 RAID 子系统可以完成比 32 多得多的磁盘同时传输请求。除此以外，如果 SQL Server 的写活动规定需要更高的磁盘传输能力，那么应将 max async I/O 设置得更高。
注意 Microsoft Windows95/98 平台不支持异步 I/O，所以此选项不适用。
能使 Checkpoint“足够快”的值即是好的 max async I/O 值。其目的是使 Checkpoint 足够快完成以便在需要下一个检查点之前结束(根据所需恢复特性)，但不能快到使系统受到事件严重干扰的程度(如磁盘队列，将在本文的后面详细进行讨论)。
为运行在大型磁盘子系统的 SQL Server 设置 max async I/O 的经验法则是用 2 或 3 乘以可同时进行 I/O 操作的物理驱动器的数量。然后监视 Performance Monitor，看是否有磁盘活动或队列问题的迹象。将此配置选项设置得过高的负面影响是 Checkpoint 可能独占磁盘子系统带宽，而其它 SQL Server I/O 操作(如读取)也需要使用磁盘子系统带宽。
要设置该值，请在 SQL Server Query Analyzer 中执行以下命令：sp_configure 'max async io', ，其中 表示在一个检查点操作过程中，SQL Server 系统可提交给 Windows的同时磁盘 I/O 请求的数量，Windows 然后又将请求提交给物理磁盘子系统。(有关详细信息，请参见本文后面的“磁盘 I/O 性能”部分。)此配置选项是动态的(也就是说，它不要求 SQL Server 停止然后重新启动才能生效)。
有关详细信息，请在 SQL Server Books Online 中搜索字符串“I/O architecture”和“max async I/O option”
联系我们
20065150
MSN: bee@beeteam.net
TEL : 021-66301038
非工作时间联系 :13817777135
地址: 上海市共和新路2999弄2号2402室