SQL Server 2005性能排错(2)
2007-05-15 09:28:39 来源:WEB开发网内存压力
内存压力表示当可用内存数量受到限制。识别SQL Server何时运行在内存压力下将帮助你排除内存相关的问题。SQL Server依赖于不同类型的内存压力特征也不一样。下表汇总了内存压力类型,和他们潜在的原因。在所有的情况下,你可以更多的会见到超时或显示的内存不足错误消息。
表 2
压力 |
外部 |
内部 |
物理 |
物理内存(RAM)运行值低。这导致系统整理当前运行的工具集,导致整体性能下降。 SQL Server监测到这种条件,依赖于配置,可以减少缓存池的目的提交并开始清理内部缓存。 |
SQL Server检测内部较高的内存消耗,导致在不同内部组件间的内存重新分配。 内部内存压力可以导致: · 导致外部内存压力(SQL Server设置地的内存使用能力)。 · 改变内存设置(例如‘max server memory’)。 · 改变内部组件的内存分布(导致预留的高百分比并从缓存池中获取页)。 |
虚拟的 |
在系统页面文件运行在较低值。这样可以导致系统分配内存失败。不能扩展当前的内存分配。这可以导致着整个系统响应很慢或者可能导致系统关机。 |
在VAS运行值低,导致分页(很多VAS可用,但是被分为小块)与/或消耗(直接分配,DLL加载到SQL VAS,大量的线程)。 SQL Server检测到这种条件并可以释放VAS中保留的区域,减少缓存池提交的目标并开始收缩缓存。 |
Windows有通知的机制 如果物理内存运行在过高或过低的情况下。SQL Server在他的内存管理决策中使用这种机制。
一般排错的步骤显示在表3中。
表 3
压力 |
内部 |
外部 |
物理 |
· 找到主要的系统内存消耗组件。 · 尝试消除消耗(如果可能)。 · 检查适当的系统RAM和考虑添加额外RAM(通常需要更仔细研究) |
· 识别SQL Server内主要的内存消耗 · 确认系统配置。 · 进一步操作依赖于研究;检查负载;可能出现的设计问题;其他的资源瓶颈。 |
虚拟 |
· 增加交换文件大小。 · 检查主要物理内存的使用和外部物理内存压力调用步骤。 |
· 外部物理内存压力调用步骤。 |
下列工具和资源可以用于排错。
◆内存相关的DMVs
◆DBCC MEMORYSTATUS 命令
◆性能计数器: 性能监视器或SQL Server指定对象的DMV
◆任务管理器
◆事件查看器: 应用程序日志和系统日志
检测内存压力
内存压力自身不会预示问题。内存压力是需要的,但时不是为服务器以后遇到内存错误的充分条件。在内存压力下工作将被任务是服务器的正常操作。然而内存压力的征兆可以于是服务器运行已经接近设计容量并且潜在存在内存不足的错误。在正常运行情况下,这些信息将作为基线决定以后内存不足的原因。
外部物理内存压力
打开人物管理器的性能视图,检查Physical Memory节的Available项的值。如果可用内存总数很低,这表现了有外部内存压力。这个准确值依赖于很多因素,然而你可以在当这个值降低到50-100MB开始查找问题。当这个总数小于10MB时,外部内存压力将表现得很明显。
相同信息也可以使用在系统监视器中的Memory: Available Bytes计数器获取。
如果存在外部内存压力并且你看到了内存相关的错误,你需要确认在系统中主要的内存消耗者。为了这个,考虑Process: Working Set性能计数器或在任务管理器中Process栏中的Mem Usage列,找到最大的内存消耗者。
系统中所有使用的物理内存可以通过汇总下列计数器获取。
◆Process 对象,每个进程的 Working Set计数器
◆Memory 对象
◆系统的Cache Bytes计数器
◆未分页池的Pool Nonpaged Bytes 计数器
◆Available Bytes (等于任务管理其中的Available 值)
如果没有外部压力,Process: Private Bytes计数器或在任务管理器中虚拟内存将接近工作集的大小(Process: Working Set或任务管理器中的Mem Usage),意味着我们没有内存用于分页了。
注意任务管理器中的Mem Usage列和相应的性能计数器不能计算通过AWE分配的内存。这样如果使用AWE,信息将是不完整的。这种情况下,你需要考虑在SQL Server内分配的内存来获取完整的信息。
你可以使用sys.dm_os_memory_clerks DMV找到SQL Server通过AWE机制分配了多少内存,如下所示。
select
sum(awe_allocated_kb) / 1024 as [AWE allocated, Mb]
from
sys.dm_os_memory_clerks
注意在SQL Server中,只有当前缓存池(’MEMORYCLERK_SQLBUFFERPOOL’类型)使用这种机制并且只能是在使用AWE功能时。通过识别和除去主要物理内存使用者(如果有可能)和/或 通过添加更多的内存的方法解除外部内存压力一般可以解决与此相关的内存问题。
外部虚拟内存压力
你需要确定是否页面文件为当前内存的分配能提供足够的空间。为了检查,可以打开任务管理器中的性能视图,并检查Commit Charge节。如果Total接近于Limit则说明可以被提交的最大数量内存没有扩展页面的空间。注意任务管理器中的Commit Charge Total指出潜在使用的页面文件,而不是实际使用值。实际使用的页面文件将增加物理内存压力。
同样可以通过下列技术起获取相关信息:Memory: Commit Limit, Paging File: %Usage, Paging File: %Usage Peak。
你可以通过每个进程的Process: Working Set减去Process Private Bytes计数器来评估内存总数。
如果Paging File: %Usage Peak(或Peak Commit Charge)很高,检查系统日志中是否有指出页面文件增长或通知“running low on virtual memory”的信息。你可能需要增加你的页面文件大小。High Paging File: %Usage指出物理内存超过要提交的值并也要考虑外部物理内存压力(大量的内存需求,没有足够的RAM)。
内部物理内存压力
内部内存压力来自于SQL Server自身,应首先通过检查在缓存分布中的异常来考虑在SQL Server内存分布。通常在SQL Server中缓存会占用最多提交的内存。为了确定在缓存池中的内存总数,我们可以使用DBCC MEMROYSTATUS命令。在Buffer Counts节,可以找到Target值。下列输出显示了在服务器达到正常负载时DBCC MEMORYSTATUS的结果。
Buffer Counts Buffers
------------------------------ --------------------
Committed 201120
Target 201120
Hashed 166517
Reserved Potential 143388
Stolen Potential 173556
External Reservation 0
Min Free 256
Visible 201120
Available Paging File 460640
Target是SQL Server计算出它在不导致分页时可以提交的8-KB每页的页数。
Target是被定期的重新计算的来反映内存的低或高。在常规服务负载下target页面过低可能预示出现了外部内存压力。
如果SQL Server占用了大量的内存(通过Process: Private Bytes或 任务管理器中Mem Usage 列显示),请查看是否Target的数值。注意,如果启用AWE,你还要从sys.dm_of_memory_clerks或DBCC MEMORYSTATUS输出计算AWE分配的总量。
考虑上面的示例(没有启用AWE),Target*8KB=1.53GB,而服务器的Process: Private Bytes大约是1.62GB或缓存池用SQL Server占用了94%的内存。注意,如果服务器没有过载,Target是应该超过Process: Private Bytes性能计数器报告的数量。
如果Target过低,但是服务器的Process: Private Bytes或 任务管理器中Mem Usage 值很高,我们也许要面对从缓存池外使用内存的组件带来的内部内存压力。被加载到SQL Server进程中的组件,例如COM对象,连接服务器,扩展存储过程,SQLCLR或其他会从缓存池外占用内存。如果不使用SQL Server内存接口,将没有方法跟踪组件在缓存池外占用的内存。
适用于SQL Server内存管理机制的组件使用在缓存池中分配很少的内存。如果分配的大于8KB,这些组将将通过多页分配器借口使用缓存池外的内存。
下列方法可以快速检查通过多业分配器接口占用的内存数量。
-- amount of mem allocated though multipage allocator interface
select sum(multi_pages_kb) from sys.dm_os_memory_clerks
你可以这样获得通过多页分配器分发内存的详细信息:
select
type, sum(multi_pages_kb)
from
sys.dm_os_memory_clerks
where
multi_pages_kb != 0
group by type
type
------------------------------------------ ---------
MEMORYCLERK_SQLSTORENG 56
MEMORYCLERK_SQLOPTIMIZER 48
MEMORYCLERK_SQLGENERAL 2176
MEMORYCLERK_SQLBUFFERPOOL 536
MEMORYCLERK_SOSNODE 16288
CACHESTORE_STACKFRAMES 16
MEMORYCLERK_SQLSERVICEBROKER 192
MEMORYCLERK_SNI 32
如果通过多页分配器分发了过大的内存( 100-200MB或更多),应该做进一步的研究。
如果你看到了通过多页分配器 分发的大量内存,检查服务器的配置并尝试使用之前或后续的查询确定哪个组件占用的最多的内存。
如果Target值低,但是在百分比上它占用了最多的内存,请在前面部分中查找描述外部内存压力的部分(External Physical Memory Pressure),或查看服务器内存配置参数。
如果你设置了max server memory 和/或min server memory,你应该用这些值和Target值进行比较。max server memory选项限制了在缓存池中占用内存的最大值,而服务器还可以占用其他的部分。min server memory选项告诉服务器当小于该值时不能释放缓存池的内存。如果Target小于min server memory设置并且服务器没有过载,这可能预示服务器遇到了外部内存压力并且不能获得这个设置大小的内存。它也可能预示着从内部组件的内存压力,就像上面描述的那样。Target 数值不能超过max server memory选项的设置。
首先,检查从DBCC MEMORYSTATUS输出中Stolen页面数量
Buffer Distribution Buffers
------------------------------ -----------
Stolen 32871
Free 17845
Cached 1513
Database (clean) 148864
Database (dirty) 259
I/O 0
Latched 0
相对于Stolen和Target页面的高百分比(>75-80%)预示着内部内存压力。
更多关于服务器组件内存分配的信息可以使用sys.dm_of_memory_clerks DMV获取。
-- amount of memory consumed by components outside the Buffer pool
-- note that we exclude single_pages_kb as they come from BPool
-- BPool is accounted for by the next query
select
sum(multi_pages_kb
+ virtual_memory_committed_kb
+ shared_memory_committed_kb) as [Overall used w/o BPool, Kb]
from
sys.dm_os_memory_clerks
where
type <> 'MEMORYCLERK_SQLBUFFERPOOL'
-- amount of memory consumed by BPool
-- note that currenlty only BPool uses AWE
select
sum(multi_pages_kb
+ virtual_memory_committed_kb
+ shared_memory_committed_kb
+ awe_allocated_kb) as [Used by BPool with AWE, Kb]
from
sys.dm_os_memory_clerks
where
type = 'MEMORYCLERK_SQLBUFFERPOOL'
每个组件的详细信息可以通过下列语句获取(这包括从缓存池内和缓存池外分配的内存)。
declare @total_alloc bigint
declare @tab table (
type nvarchar(128) collate database_default
,allocated bigint
,virtual_res bigint
,virtual_com bigint
,awe bigint
,shared_res bigint
,shared_com bigint
,topFive nvarchar(128)
,grand_total bigint
);
-- note that this total excludes buffer pool committed memory as
it represents the largest consumer which is normal
select
@total_alloc =
sum(single_pages_kb
+ multi_pages_kb
+ (CASE WHEN type <> 'MEMORYCLERK_SQLBUFFERPOOL'
THEN virtual_memory_committed_kb
ELSE 0 END)
+ shared_memory_committed_kb)
from
sys.dm_os_memory_clerks
print
'Total allocated (including from Buffer Pool): '
+ CAST(@total_alloc as varchar(10)) + ' Kb'
insert into @tab
select
type
,sum(single_pages_kb + multi_pages_kb) as allocated
,sum(virtual_memory_reserved_kb) as vertual_res
,sum(virtual_memory_committed_kb) as virtual_com
,sum(awe_allocated_kb) as awe
,sum(shared_memory_reserved_kb) as shared_res
,sum(shared_memory_committed_kb) as shared_com
,case when (
(sum(single_pages_kb
+ multi_pages_kb
+ (CASE WHEN type <> 'MEMORYCLERK_SQLBUFFERPOOL'
THEN virtual_memory_committed_kb
ELSE 0 END)
+ shared_memory_committed_kb))/(@total_alloc + 0.0)) >= 0.05
then type
else 'Other'
end as topFive
,(sum(single_pages_kb
+ multi_pages_kb
+ (CASE WHEN type <> 'MEMORYCLERK_SQLBUFFERPOOL'
THEN virtual_memory_committed_kb
ELSE 0 END)
+ shared_memory_committed_kb)) as grand_total
from
sys.dm_os_memory_clerks
group by type
order by (sum(single_pages_kb + multi_pages_kb + (CASE WHEN type <>
'MEMORYCLERK_SQLBUFFERPOOL' THEN virtual_memory_committed_kb ELSE 0 END)
+ shared_memory_committed_kb)) desc
select * from @tab
注意之前的查询将Buffer Pool与通过单页分配器提供给组件的内存视为不同的部分。通过下列查询可以确定在缓存池中耗费内存最多的10个组件(通过单页分配器)。
-- top 10 consumers of memory from BPool
select
top 10 type,
sum(single_pages_kb) as [SPA Mem, Kb]
from
sys.dm_os_memory_clerks
group by type
order by sum(single_pages_kb) desc
你通常不会控制内部组件对内存的占用。然而,确定哪个组件占用最多的内存可以帮助对问题的后续研究。
系统监视器(Perfmon)
你也可以通过检查下列计数器来确定内存压力(SQL Server联机丛书中有详细地描述):
SQL Server: Buffer Manager 对象
◆Low Buffer cache hit ratio
◆Low Page life expectancy
◆High number of Checkpoint pages/sec
◆High number Lazy writes/sec
不足的内存和I/O开销经常会导致瓶颈。请查看本文的I/O 瓶颈部分。
高速缓存和内存压力
查看外部和内部内存压力的方法是查看内存中高速缓存的行为。
SQL Server 2005与SQL Server 2000的高速缓存设计上有一些细微的不同,其中之一就是统一了高速缓存的框架。为了从高速缓存中删除最近很少使用的项,该框架实现了一套时钟算法。现在它使用2支不同的时钟指针,一个是内部时钟指针,一个是外部时钟指针。
内部时钟指针控制与其他高速缓存相关的缓存大小。当框架预测到高速缓存要使用到尽头是它开始移动。
当SQL Server总体上陷入内存压力时,外部时钟指针开始移动。外部时钟指针的移动可以导致外部和内部的内存压力。在内部和外部内存压力时不会混乱的移动外部时钟和内部时钟。
关于时钟移动的信息可以通过sys.dm_os_memory_cache_clock_hands DMV显示,如下代码所示。每个高速缓存项在内部和外部时钟指针都有不同的行。如果你看到rounds count和removed all rounds count增加,说明服务器遇到内部/外部内存压力。
select *
from
sys.dm_os_memory_cache_clock_hands
where
rounds_count > 0
and removed_all_rounds_count > 0
通过如下所示,通过通过sys.dm_os_cache_counters DMV你可以获得更多关于缓存的信息。
select
distinct cc.cache_address,
cc.name,
cc.type,
cc.single_pages_kb + cc.multi_pages_kb as total_kb,
cc.single_pages_in_use_kb + cc.multi_pages_in_use_kb as total_in_use_kb,
cc.entries_count,
cc.entries_in_use_count,
ch.removed_all_rounds_count,
ch.removed_last_round_count
from
sys.dm_os_memory_cache_counters cc
join sys.dm_os_memory_cache_clock_hands ch on (cc.cache_address = ch.cache_address)
/*
--uncomment this block to have the information only for moving hands caches
where
ch.rounds_count > 0
and ch.removed_all_rounds_count > 0
*/
order by total_kb desc
注意USERSTORE项,正在使用的页面数量将不会被报告,因为结果将是NULL。
Ring buffers
更多有意义的内存调试信息可以通过sys.dm_os_ring_buffers的ring buffers DMV获取。每个ring buffer保留了之前几次某种类型的通知。指定ring buffer的详细信息将在下面描述。
RING_BUFFER_RESOURCE_MONITOR
你可以使用从资源监视器的通知识别内存改变的状态。在内部,SQL Server有一个监视不同内存压力的架构。当内存状态改变,资源监视器任务生成一个通知。这个通知用于内部组件根据内存状态调整它们内存使用并通过sys.dm_os_ring_buffers DMV来暴露,如下列代码所示。
select record
from sys.dm_os_ring_buffers
where ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR'
结果类似于:
<Record id="1701" type="RING_BUFFER_RESOURCE_MONITOR" time="149740267">
<ResourceMonitor>
<Notification>RESOURCE_MEMPHYSICAL_LOW</Notification>
<Indicators>2</Indicators>
<NodeId>0</NodeId>
</ResourceMonitor>
<MemoryNode id="0">
<ReservedMemory>1646380</ReservedMemory>
<CommittedMemory>432388</CommittedMemory>
<SharedMemory>0</SharedMemory>
<AWEMemory>0</AWEMemory>
<SinglePagesMemory>26592</SinglePagesMemory>
<MultiplePagesMemory>17128</MultiplePagesMemory>
<CachedMemory>17624</CachedMemory>
</MemoryNode>
<MemoryRecord>
<MemoryUtilization>50</MemoryUtilization>
<TotalPhysicalMemory>3833132</TotalPhysicalMemory>
<AvailablePhysicalMemory>3240228</AvailablePhysicalMemory>
<TotalPageFile>5732340</TotalPageFile>
<AvailablePageFile>5057100</AvailablePageFile>
<TotalVirtualAddressSpace>2097024</TotalVirtualAddressSpace>
<AvailableVirtualAddressSpace>336760</AvailableVirtualAddressSpace>
<AvailableExtendedVirtualAddressSpace>0</AvailableExtendedVirtualAddressSpace>
</MemoryRecord>
</Record>
从这些记录来看,你可以减少服务器收到的低物理内存的通知。你也可以查看内存总量(KB为单位)。你可以通过使用SQL Server的XML能力来查询这些信息,例如下列代码。
select
x.value('(//Notification)[1]', 'varchar(max)') as [Type],
x.value('(//Record/@time)[1]', 'bigint') as [Time Stamp],
x.value('(//AvailablePhysicalMemory)[1]', 'int') as [Avail Phys Mem, Kb],
x.value('(//AvailableVirtualAddressSpace)[1]', 'int') as [Avail VAS, Kb]
from
(select cast(record as xml)
from sys.dm_os_ring_buffers
where ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR') as R(x)
order by
[Time Stamp] desc
上面收到了低内存的通知,缓存池重新计算target。注意target数量保持在指定的min server memory 和max server memory选项限制中。如果缓存池中心的提交比当前的提交缓存还小,缓存池将开始收缩直到外部内存压力被移除。注意,当运行在启用AWE时SQL Server 2000不是这样来缓解物理内存压力的。
RING_BUFFER_OOM
下列代码示例,展示了ring buffer中包含预示服务器内存不足的记录。
select record
from sys.dm_os_ring_buffers
where ring_buffer_type = 'RING_BUFFER_OOM'
结果类似于:
<Record id="7301" type="RING_BUFFER_OOM" time="345640123">
<OOM>
<Action>FAIL_VIRTUAL_COMMIT</Action>
<Resources>4096</Resources>
</OOM>
这条记录告诉我们那个操作失败了(提交,保留或页面分配)并表明了请求的内存数量。
RING_BUFFER_MEMORY_BROKER and Internal Memory Pressure
当监测到内部内存压力时,为组件在缓存池分配内存的低内存通知将被打开。打开低内存通知允许从使用缓存池的高速缓存和其他组件中回收页面。
内部内存压力可以通过调整max server memory选项或当stolen页面与缓存池的比例超过80%时触发。
内部内存压力通知(‘Shrink’)能通过使用下列代码查询ring buffer的调用来发现。
select
x.value('(//Record/@time)[1]', 'bigint') as [Time Stamp],
x.value('(//Notification)[1]', 'varchar(100)') as [Last Notification]
from
(select cast(record as xml)
from sys.dm_os_ring_buffers
where ring_buffer_type = 'RING_BUFFER_MEMORY_BROKER') as R(x)
order by
[Time Stamp] desc
RING_BUFFER_BUFFER_POOL
ring buffer将包含预示严重的缓存池失败的记录,包括缓存池溢出的条件。
select record
from sys.dm_os_ring_buffers
where ring_buffer_type = 'RING_BUFFER_BUFFER_POOL'
结果类似于:
<Record id="1234" type="RING_BUFFER_BUFFER_POOL" time="345640123">
< BufferPoolFailure id="FAIL_OOM">
<CommittedCount>84344 </CommittedCount>
<CommittedTarget>84350 </CommittedTarget >
<FreeCount>20</FreeCount>
<HashedCount>20345</HashedCount>
<StolenCount>64001 </StolenCount>
<ReservedCount>64001 </ReservedCount>
</ BufferPoolFailure >
这条记录告诉我们出现了什么样的失败 (FAIL_OOM, FAIL_MAP,FAIL_RESERVE_ADJUST,FAIL_LAZYWRITER_NO_BUFFERS) 基当时的缓存池状态。
内部虚拟内存压力
VAS的占用可以使用sys.dm_os_virtual_address_dump DMV来跟踪。VAS汇总可以使用下列视图来查询。
-- virtual address space summary view
-- generates a list of SQL Server regions
-- showing number of reserved and free regions of a given size
CREATE VIEW VASummary AS
SELECT
Size = VaDump.Size,
Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0) WHEN 0 THEN 0 ELSE 1 END),
Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0) WHEN 0 THEN 1 ELSE 0 END)
FROM
(
--- combine all allocation according with allocation base, don't take into
--- account allocations with zero allocation_base
SELECT
CONVERT(VARBINARY, SUM(region_size_in_bytes)) AS Size,
region_allocation_base_address AS Base
FROM sys.dm_os_virtual_address_dump
WHERE region_allocation_base_address <> 0x0
GROUP BY region_allocation_base_address
UNION
--- we shouldn't be grouping allocations with zero allocation base
--- just get them as is
SELECT CONVERT(VARBINARY, region_size_in_bytes), region_allocation_base_address
FROM sys.dm_os_virtual_address_dump
WHERE region_allocation_base_address = 0x0
)
AS VaDump
GROUP BY Size
下列查询可以用于访问VAS状态:
-- available memory in all free regions
SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB]
FROM VASummary
WHERE Free <> 0
-- get size of largest availble region
SELECT CAST(MAX(Size) AS INT)/1024 AS [Max free size, KB]
FROM VASummary
WHERE Free <> 0
如果最大可用区域小于4MB,我们可能遇到了VAS压力。SQL Server 2005监视和响应VAS压力。SQL Server 2000不会监视从VAS带来的压力,但是当出现虚拟内存不足错误是,它会清理高速缓存。
一般的内存错误排错步骤
下列是一些常规步骤,有助于你排除内存错误。
1.验证是否服务器运行在外部内存压力。如果出现外部内存压力,尝试先解决它,然后再看是否依然存在这个问题或错误。
2.开始收集性能计数器:SQL Server: Buffer Manager, SQL Server: Memory Manager
3.确认内存配置参数(sp_configure), min memory per query,min/max server memory,awe enabled和 Lock Pages in Memory 权利。观察不正常的值。纠正配置。提供为SQL Server 2005增加内存的理由。
4.检查所有可能影响服务器的非默认sp_configure参数。
5.检查内部内存压力。
6.当你见到内存错误消息时,观察DBCC MEMORYSTATUS输出和改变的方法。
7.检查负载(并发会话数量,并发执行查询数量)。
内存错误
701 - There is insufficient system memory to run this query.
原因
这是服务器内存不足的典型现象。它预示了内存分配失败。它可以有多种原因导致,包括在当前工作负载上的内存提示。通过增加SQL Server 2005需要的内存和一些配置上的设置(例如max server memory选项)用户可能会看到这种错误。通常失败的事务不是因为这个错误。
- ››SQL Server 2008 R2 下如何清理数据库日志文件
- ››sqlite 存取中文的解决方法
- ››SQL2005、2008、2000 清空删除日志
- ››SQL Server 2005和SQL Server 2000数据的相互导入...
- ››sql server 2008 在安装了活动目录以后无法启动服...
- ››sqlserver 每30分自动生成一次
- ››sqlite 数据库 对 BOOL型 数据的插入处理正确用法...
- ››sql server自动生成批量执行SQL脚本的批处理
- ››sql server 2008亿万数据性能优化
- ››SQL Server 2008清空数据库日志方法
- ››sqlserver安装和简单的使用
- ››SQL Sever 2008 R2 数据库管理
更多精彩
赞助商链接