Windows8 安装SQL server2008 遇到以下问题，怎么解决？

微软自SQL 2008以后提供了一个图形化的活动监视器来帮助DBA观察"当前的"阻塞现象. 详情请参考 (点击打开链接). DBA需要关注如下的信息列去

会话 ID：　是建立连接时分配给每个用户连接的唯一整数 (int)。

等待时间(毫秒):此任务等待资源所用的时间（毫秒）。如果任务没有等待，则等待时间为 0。

等待类型：最近或当前等待类型的名称。

等待资源：所需资源的名称。

阻塞者：如果有阻塞会话，则为正阻塞任务的会话的 ID。

头阻塞程序：如果有阻塞会话，则标识导致第一个阻塞条件的会话。

值为 1 表示其他会话的头阻塞程序。

通常我们提到队头阻塞，指的可能是TCP协议中的队头阻塞，但是HTTP1.1中也有一个类似TCP队头阻塞的问题，下面各自介绍一下。

队头阻塞（head-of-line blocking）发生在一个TCP分节丢失，导致其后续分节不按序到达接收端的时候。该后续分节将被接收端一直保持直到丢失的第一个分节被发送端重传并到达接收端为止。该后续分节的延迟递送确保接收应用进程能够按照发送端的发送顺序接收数据。这种为了达到完全有序而引入的延迟机制非常有用，但也有不利之处。

假设在单个TCP连接上发送语义独立的消息，比如说服务器可能发送3幅不同的图像供Web浏览器显示。为了营造这几幅图像在用户屏幕上并行显示的效果，服务器先发送第一幅图像的一个断片，再发送第二幅图像的一个断片，然后再发送第三幅图像的一个断片；服务器重复这个过程，直到这3幅图像全部成功地发送到浏览器为止。

要是第一幅图像的某个断片内容的TCP分节丢失了，客户端将保持已到达的不按序的所有数据，直到丢失的分节重传成功。这样不仅延缓了第一幅图像数据的递送，也延缓了第二幅和第三幅图像数据的递送。

上面用浏览器请求图片资源举例子，但实际上HTTP自身也有类似TCP队头阻塞的情况。要介绍HTTP队头阻塞，就需要先讲讲HTTP的管道化（pipelining）。

HTTP管道化是什么

HTTP1.1 允许在持久连接上可选的使用请求管道。这是相对于keep-alive连接的又一性能优化。在相应到达之前，可以将多条请求放入队列，当第一条请求发往服务器的时候，第二第三条请求也可以开始发送了，在高延时网络条件下，这样做可以降低网络的环回时间，提高性能。

非管道化与管道化的区别示意

在一般情况下，HTTP遵守“请求-响应”的模式，也就是客户端每次发送一个请求到服务端，服务端返回响应。这种模式非常容易理解，但是效率并不是那么高，为了提高速度和效率，人们做了很多尝试：

最简单的情况下，服务端一旦返回响应后就会把对应的连接关闭，客户端的多个请求实际上是串行发送的。

除此之外，客户端可以选择同时创建多个连接，在多个连接上并行的发送不同请求。但是创建更多连接也带来了更多的消耗，当前大部分浏览器都会限制对同一个域名的连接数。

从HTTP1.0开始增加了持久连接的概念（HTTP1.0的Keep-Alive和HTTP1.1的persistent），可以使HTTP能够复用已经创建好的连接。客户端在收到服务端响应后，可以复用上次的连接发送下一个请求，而不用重新建立连接。

现代浏览器大多采用并行连接与持久连接共用的方式提高访问速度，对每个域名建立并行地少量持久连接。

而在持久连接的基础上，HTTP1.1进一步地支持在持久连接上使用管道化（pipelining）特性。管道化允许客户端在已发送的请求收到服务端的响应之前发送下一个请求，借此来减少等待时间提高吞吐；如果多个请求能在同一个TCP分节发送的话，还能提高网络利用率。但是因为HTTP管道化本身可能会导致队头阻塞的问题，以及一些其他的原因，现代浏览器默认都关闭了管道化。

管道化要求服务端按照请求发送的顺序返回响应（FIFO），原因很简单，HTTP请求和响应并没有序号标识，无法将乱序的响应与请求关联起来。

客户端需要保持未收到响应的请求，当连接意外中断时，需要重新发送这部分请求。

只有幂等的请求才能进行管道化，也就是只有GET和HEAD请求才能管道化，否则可能会出现意料之外的结果

HTTP管道化引起的请求队头阻塞

前面提到HTTP管道化要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达。

如何解决HTTP队头阻塞

对于HTTP1.1中管道化导致的请求/响应级别的队头阻塞，可以使用HTTP2解决。HTTP2不使用管道化的方式，而是引入了帧、消息和数据流等概念，每个请求/响应被称为消息，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。每个帧在传输是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后在组装成消息，这样就避免了请求/响应阻塞。

当然，即使使用HTTP2，如果HTTP2底层使用的是TCP协议，仍可能出现TCP队头阻塞。

TCP中的队头阻塞的产生是由TCP自身的实现机制决定的，无法避免。想要在应用程序当中避免TCP队头阻塞带来的影响，只有舍弃TCP协议。

比如google推出的quic协议，在某种程度上可以说避免了TCP中的队头阻塞，因为它根本不使用TCP协议，而是在UDP协议的基础上实现了可靠传输。而UDP是面向数据报的协议，数据报之间不会有阻塞约束。

此外还有一个SCTP（流控制传输协议），它是和TCP、UDP在同一层次的传输协议。SCTP的多流特性也可以尽可能的避免队头阻塞的情况。

从TCP队头阻塞和HTTP队头阻塞的原因我们可以看到，出现队头阻塞的原因有两个：

微软自SQL

2008以后提供了一个图形化的活动监视器来帮助DBA观察"当前的"阻塞现象.

详情请参考

(点击打开链接).

DBA需要关注如下的信息列去

会话

ID：　是建立连接时分配给每个用户连接的唯一整数

(int)。

等待时间(毫秒):此任务等待资源所用的时间（毫秒）。如果任务没有等待，则等待时间为

0。

等待类型：最近或当前等待类型的名称。

等待资源：所需资源的名称。

阻塞者：如果有阻塞会话，则为正阻塞任务的会话的

ID。

头阻塞程序：如果有阻塞会话，则标识导致第一个阻塞条件的会话。

值为

1

表示其他会话的头阻塞程序。

---