实验1 远程客户机能否通过共享内存访问服务器

实验目的

SQL Server 2000网络提供了一种称为共享内存的机制。共享内存是一种在同一个Windows 操作系统的进程间的通信机制。也就是说,在物理上同一台计算机上的进程间的通信机制就是共享内存。

如果SQL Server 2000的服务器和客户机安装在物理上的同一台计算机上(本地客户机),是可以通过共享内存来访问的,而且这样的速度也是最快的。

如果SQL Server 2000的客户机和服务器在物理上不同的计算机上(远程客户机),能不能够通过共享内存机制来访问呢?

本实验将对上述问题给出正确的答案。

实验环境

本实验的环境如图1.1所示。SQL Server 2000服务器同时也是SQL Server 2000客户机。

图1.1 测试共享内存机制的SQL Server 2000网络实验环境

实验方法

Windows 2000的【控制面板】/【管理工具】/【事件查看器】工具可以监控SQL Server 2000更改配置参数后的启动过程。通过查看【事件查看器】记录的事件可以分析SQL Server 2000服务器端参数的更改后服务器是如何启动的。

实验将SQL Server 2000服务器配置为【共享内存】模式后,分别用同一台计算机上的SQL Server 2000客户机和物理上不同计算机上的SQL Server 2000客户机通过共享内存机制来访问SQL Server 2000服务器,验证共享内存机制。

实验步骤

1.SQL Server 2000服务器上的操作

(1)在SQL Server 2000服务器上启动【服务器网络实用工具】,出现如图1.2所示的【常规】选项卡。在【启用的协议】列表框中不要启用任何协议。完成后单击 按钮。

图1.2 将服务器配置为共享内存

(2)出现如图1.3所示的【提示信息】界面。提示禁止使用所有的协议,无法接受远程客户机的请求。单击 按钮。

图1.3 【提示信息】界面

(3)出现如图1.4所示的【提示重新启动服务】界面。SQL Server服务器网络配置参数改变后要求重新启动服务,参数才能生效。单击 按钮。

图1.4 【提示重新启动服务】界面

(4)启动【事件查看器】,在【树】下选择【事件查看器】/【应用程序日志】选项用鼠标右键单击,在出现的快捷菜单中选择【清除所有事件】选项。SQL Server 2000服务器的启动过程产生的事件将记录在这里。

图1.5 清除【事件查看器】的事件

(5)通过SQL Server 2000的【服务管理器】启动SQL Server 2000服务,如图1.6所示。

图1.6 启动SQL Server 2000服务

(6)在【事件查看器】中产生如图1.7所示的事件,对这些事件进行分析就可以获得共享内存的SQL Server 2000服务器的启动过程。

图1.7 产生的事件

(7)实验环境产生的事件内容分析如下。/**/内的内容为作者添加的说明性内容。

―――――――――――――――――――――――――――――――――――――

/第1条事件,阐述了SQL Server 的版本信息,安装环境的操作系统版本/

2005-5-29 11:47:05 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER "17052:

Microsoft SQL Server 2000 - 8.00.760 (Intel X86)

Dec 17 2002 14:22:05

Copyright (c) 1988-2003 Microsoft Corporation

Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 4)"

/第2条事件,为SQL Server 2000分配的服务器进程ID/

2005-5-29 11:47:05 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER 17104:

服务器进程 ID 是 500。

/第3条事件,SQL Server 2000实例上一次运行使用的进程ID/

2005-5-29 11:47:05 MSSQLSERVER 信息 (2) 17176 N/A MYNETSERVER 此 SQL Server 实例最近于 2005-5-29 11:46:34 (本地) 2005-5-29 3:46:34 (UTC)报告使用的进程 ID 是 1256。

/第4条事件,SQL Server 2000安装在一个CPU的服务器上,以正常优先级开始启动/

2005-5-29 11:47:05 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER 17162:

SQL Server 正在以优先级“normal”(已检测到 1 CPU)启动。

/第5条事件,SQL Server 2000的CPU配置为线程模式/

2005-5-29 11:47:05 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER 17124:

已为 thread 模式处理而配置了 SQL Server。

/第6条事件,为SQL Server 2000分配的锁信息/

2005-5-29 11:47:05 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER 17125:

使用 dynamic 锁分配。[2500] 锁块,[5000] 锁所有者块。

/第7条事件,启用默认的由SSNETLIB.DLL文件封装的网络库超级套接字,图1.8说明了该文件封装了TCP/IP协议和NWlink IPX/SPX两种通信协议/

2005-5-29 11:47:07 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER 17834:

正在使用“SSNETLIB.DLL”版本“8.0.766”。

/第8条事件,由于在图1.2中配置不使用TCP/IP协议和NWlink IPX/SPX两种通信协议,所以这里提示无法注册超级套接字网络库/

2005-5-29 11:47:09 MSSQLServer 警告 (8) 19011 N/A MYNETSERVER SuperSocket 信息: (SpnRegister) : Error 1355。

/第9条事件,尽管没有明确配置启用共享内存机制,但SQL Server 2000自动启动共享内存机制/

2005-5-29 11:47:09 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER 19013:

SQL Server 正在监听 Shared Memory。

/第10条事件,已经准备好进行客户机连接/

2005-5-29 11:47:09 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER 17126:

SQL Server 已准备好进行客户端连接

/第11条事件,启动完成。/

2005-5-29 11:47:10 MSSQLSERVER 信息 (2) 17055 N/A MYNETSERVER 17052:

恢复完成。

―――――――――――――――――――――――――――――――――――――

【配套光盘文件】:\第1章\0101.txt。

(8)图1.8所示为【服务器网络实用工具】的【网络库】选项卡。说明了各网络库封装的网络通信协议。网络库是以动态链接库 DLL形式实现的IPC(进程间通信)机制。IPC机制的实现对于一般用户来讲是很复杂的,网络库将IPC机制的内部实现进行了封装,留出的部分很容易配置的参数供用户进行设置。网络库必须成对出现,也就是说,客户机和服务器选择的网络库必须是一致的。当客户机和服务器通过某种特定的网络库进行通信时,实际上就是两者选择相同的网络通信协议、相同的IPC机制来进行通信。网络库不是通信协议,而是通信协议和IPC机制组合的结果。

图1.8 SSNETLIB网络库封装的网络协议

2.本地客户机的操作

(1)在SQL Server 2000客户机上启动【客户端网络实用工具】,出现如图1.9所示的【常规】选项卡。在【按顺序启动协议】列表框中禁用所有的协议。选择【启用共享内存协议】服选框。用【查询分析器】测试连接成功。如图1.10所示。

图1.9 在客户机上启用共享内存协议 图1.10 测试连接成功

(2)在SQL Server 2000客户机的【客户端网络实用工具】的【常规】选项卡不选择【启用共享内存协议】服选框,如图1.11所示。用【查询分析器】测试连接,出现如图1.12所示的共享内存的服务器不存在或者拒绝访问的信息。如图1.13所示。

图1.11 在客户机上不启用共享内存协议 图1.12 测试连接不成功

3.远程客户机的操作

在远程SQL Server 2000客户机的【客户端网络实用工具】的【常规】选项卡中选择【启用共享内存协议】服选框,用【查询分析器】测试连接,出现如图1.13所示的服务器不存在或者拒绝访问的信息。

图1.13 远程客户机无法通过共享内存进行访问

实验结论

本实验可以得出的结论有3点。

(1)网络库不等于网络通信协议。

(2)共享内存通信机制仅仅适合本地客户机访问SQL Server 2000服务器。远程客户机不能采用该机制。

(3)TCP/IP协议的优先次序优于共享内存。

【实验视频文件】:\第1章\0101.exe。

Published At
Categories with 数据库类
Tagged with
comments powered by Disqus