SQLServer数据库内存会不断增加的问题分析

当 SQL Server 数据库引擎在 Microsoft® Windows NT® 或 Windows® 2000 上运行时，其默认内存管理行为并不是获取特定的内存量，而是在不产生多余换页 I/O 的情况下获取尽可能多的内存。为此，数据库引擎获取尽可能多的可用内存，同时保留足够的可用内存以防 *** 作系统交换内存。

SQL Server 实例在启动时通常获取 8 到 12 MB 的内存以完成初始化过程。当实例完成初始化后，就不会再获取更多的内存，直到用户连接到该实例并开始产生工作负荷。这时，该实例根据需要不停地获取内存以支持工作负荷。随着更多的用户连接并运行查询，SQL Server 将获取支持需求所需的额外内存。该实例将继续获取内存直到达到自身的内存分配目标，并且直到达到该目标的下限才会释放任何内存。

为了在不产生多余换页 I/O 的情况下获取尽可能多的内存，SQL Server 的每个实例都设置一个内存获取目标，直到计算机的可用物理内存在 4 MB 到 10 MB 的范围内。之所以选择该范围是因为测试表明 Windows NT 和 Windows 2000 都有最小内存交换，直到内存分配等于可用物理内存减去 4 MB。工作负荷处理任务重的 SQL Server 实例保留的可用物理内存为范围的较低端 (4 MB)；工作负荷处理任务轻的实例保留的可用物理内存为范围的较高端 (10 MB)。

SQL Server 实例的目标随工作负荷的改变而变化。当更多的用户连接并产生更多的工作时，该实例倾向于获取更多的内存以使可用的内存保持在 4 MB 的限制以下。当工作负荷减轻时，该实例将其目标调整为 10 MB 的可用空间，并释放内存给 *** 作系统。将可用空间量保持在 10 MB 与 4 MB 之间可防止 Windows NT 或 Windows 2000 过多执行换页 *** 作，同时使 SQL Server 得以获得尽可能的高速缓冲存储器而不至引起额外的交换。

实例的目标内存设置与数据库缓冲池的页相对于可用池大小的需求有关。在任何即时点，缓冲区页的总需求取决于满足所有当前执行的查询所需的数据页数。如果相对于高速缓冲存储器内的页数，数据页的需求很大，则当前在缓冲区内的每一页很可能在相对较短的时间内由新页替换。这可由"缓冲区管理器"对象的"页生命期"性能计数器来度量。对于相对较小的缓冲区有较高需求的情况将生成短生命期，而纯粹的影响就是使 I/O 增加，因为在页可由多个逻辑读取引用之前往往要被重写。为减轻这个问题，数据库引擎可以获取更多的内存以增加高速缓冲存储器的大小。当页生命期长时，数据库引擎将可用内存定位于目标的高端 (10 MB)；而当页生命期短时，数据库引擎定位于目标范围的低端 (4 MB)。

随着其它应用程序在运行 SQL Server 实例的计算机上启动，它们消耗内存致使可用物理内存量降到 SQL Server 的目标以下。SQL Server 实例于是从其地址空间释放足够内存，以使可用内存量回到 SQL Server 的目标。如果有其它应用程序停止运行而使可用内存增多，SQL Server 实例将增加其内存分配大小。SQL Server 可以每秒释放并获取几 MB 字节的内存，这使它得以根据内存分配变化作出快速调整。　可以通过设置允许sql server可以使用的内存来做限制：最小和服务器内存的影响

min server memory 和 max server memory 配置选项建立由 SQL Server 数据库引擎使用的内存量的上限和下限。数据库引擎并不立即获取 min server memory 中指定的内存量。数据库引擎启动时只使用初始化所需的内存。随着数据库引擎工作负荷的增加，它将继续获取支持工作负荷所需的内存。数据库引擎直到到达 min server memory 中指定的内存量才会释放任何所需的内存。一旦到达 min server memory，数据库引擎将使用标准算法（使 *** 作系统的可用内存保持在 4 MB 到 10 MB 之间）获取和释放所需内存。的区别是数据库引擎从不将内存分配降到 min server memory 所指定的水平下，也从不获取超过max server memory 所指定水平的内存。

数据库引擎获取的内存量完全取决于放置在实例上的工作负荷。不处理很多请求的 SQL Server 实例可能永远达不到 min server memory。

如果为 min server memory 和 max server memory 指定相同的值，则一旦分配给数据库引擎的内存达到该值，数据库引擎将停止动态释放和获取内存。

如果在运行 SQL Server 实例的计算机上频繁启动或停止其它应用程序，启动这些应用程序所需的时间可能会因 SQL Server 实例分配和释放内存而延长。另外，如果 SQL Server 是几个在一台计算机上运行的服务器应用程序中的一个，系统管理员可能需要控制分配给 SQL Server 的内存量。在这些情况下，可以使用 min server memory 和 max server memory 选项控制 SQL Server 可以使用的内存量。

何设置固定的内存量（企业管理器）

设置固定的内存量

展开一个服务器组。

右击一个服务器，再单击"属性"。

单击"内存"选项卡。

单击"使用固定的内存大小 (MB)"，然后将固定内存滑块放在适当的位置。

说明:

如果使用默认设置，则 Microsoft® SQL Server™ 将动态配置内存。这是由sql server的内存管理机制决定的。

在升级或安装数据库的时候，会遇到数据库版本不对的问题，无论怎么升级，升级提示成功了，但打开数据库发现还是原来那个版本。甚至出现重装数据库之后，登陆页面已经提示安装的是新版本了，但登陆进去之后，发现数据库的版本还是原来的那个。 原因分析：数据

在升级或安装数据库的时候，会遇到数据库版本不对的问题，无论怎么升级，升级提示成功了，但打开数据库发现还是原来那个版本。甚至出现重装数据库之后，登陆页面已经提示安装的是新版本了，但登陆进去之后，发现数据库的版本还是原来的那个。

原因分析：数据库的每一个实例名对应一个数据库版本，要想登陆高版本就要用高版本的实例名。升级之后，如果我们还用低版本的实例名登陆的话，我们看到的还是低版本的数据库。

解决办法：

首先，升级或重装成功了数据库

然后

上面“数据库引擎”下的即是实例名。选择相应的点确定登陆进去，就可以看到相应版本的数据库了。

全国统，关于数据库备份还原工具常见问题

通过数据库备份还原工具还原数据后，显示应用程序版本与数据库版本不一致时如何解决？

解决方法一：

解决方法二：

1、点击提示上面的关闭按钮----然后点击数据上报----将要备份数据的单位前面的勾选框打钩----点击下一步----点击导出数据----点击保存旁边的小三角选择另存为选项----选择备份到系统盘和桌面以外的文件夹（如D：新建文件夹）----点击打开----点击保存。具体 *** 作，如图所示。

2、打开开始菜单----选择所有程序----点击内年度统计系统（全国版）----选择卸载内年度统计系统（全国版）选项----选择除去选项----下一步，然后卸载掉当前系统。具体 *** 作，如图所示。

3、打开内年度统计系统安装包----选择setupexe文件----点击右键选择以管理员身份运行----点击下一步----点击下一步-----点击安装。具体 *** 作，如图所示。

4、右键统图标选择以管理员身份运行----点击数据接收功能----点击浏览----选中备份文件点击打开----点击确定----点击下一步----点击数据导入。具体 *** 作，如图所示。

性能问题总是数据库领域里面永恒的话题，使用 DB2 作为底层数据平台的 SAP 系统为我们提供了许多方法监控和检测数据库性能问题。本文从数据库性能问题检测的一般思路和方法论入手，介绍了如何通过 SAP 系统对 DB2 的性能进行监控和分析。回页首数据库性能问题检测的思路及方法论在数据库运维工作中遇到性能问题时，通常会让数据库管理员感到无从下手，不容易断定问题的根源所在。如果能有一种可 *** 作的一般性的方法作为指导，我们通常就能够发现大部分数据库性能问题的根源。那么，首先根据我们对数据库性能监控的一些实践经验来总结一下在遇到性能问题时应该进行哪些检查。我们不能保证通过文中介绍的方法就能找到所有性能瓶颈，性能问题的原因很多，解决方法也多种多样，我们在这里只是提供一些普遍的，一般性的方法，具体的实施还需要根据系统的具体情况和不断的实践经验积累。同时，通过进行这些监控，也有利于为技术支持人员提供更详细诊断信息，以便于快速定位性能问题。当遇到一个性能问题，我们首先进行以下排查: 性能问题是在何时发生的; 性能问题持续存在的还是间断性的; 系统范畴的性能问题还是数据库本身的性能问题; 性能问题是否只存在于某一个应用; 性能问题是随机出现的还是必然出现的。如果性能问题存在于所有应用，我们可以进行以下排查: 如果发现系统存在大量的 I/O *** 作: 检查设备使用情况; 检查排序情况和临时表空间; 检查查询性能是否有效的得到优化; 检查缓冲池的使用状况。 如果发现 CPU 具有很高的负载: 检查排序状况; 检查缓冲池的使用状况。 如果发现 CPU 和 I/O *** 作的负荷都很大: 检查用户数量; 检查排序状况。 如果发现 CPU 和 I/O *** 作的负荷都很小而数据库响应仍然很慢: 检查并发性和锁的使用状况; 检查缓冲池的使用状况。如果性能问题可以被定位在一个应用，我们可以进行以下排查: 检查排序情况。 检查并发性和锁的使用状况。 检查统计信息是否更新。回页首通过SAP 系统的工具对 DB2 UDB 进行监控通过前一部分的描述，我们了解到了在遇到性能问题以后应该用什么思路寻找性能的瓶颈，从而想办法解决性能问题。在对数据库进行检查的过程中，我们通常会用到数据管理工具，命令行以及 *** 作系统的工具，还要结合 SAP 的自身特点寻找性能问题的根源，这将是一个比较繁琐和费事的工作。在使用 SAP 作为底层数据库的 SAP 系统中，由于 SAP 实现了与 DB2 紧密的结合。SAP 的 DBA Cockpit 提供了许多功能来支持数据库的管理工作，使得数据库性能监控和分析变得更加简单。下面我们就来看看，SAP 为 DB2 性能监控和分析提供了哪些支持。磁盘I/O 性能监控概念对于数据库来说，最消耗时间的 *** 作实际上是从磁盘中检索数据。这是由磁盘的物理特性决定的。尽管磁盘存储技术已经取得了极大的进步，但磁盘的读写速度与内存的读写速度仍然相差几个数量级。从性能调整的角度来说，如果一个机器的磁盘出现问题，那么其他的任何优化工作都无法提供帮助。因此我们应该保证运行数据库的磁盘系统是健康的。SAP 系统为我们提供了监控磁盘读写速度的功能，让我们可以直接了解当前磁盘的性能状况。监控我们首先进入 SAP 的 DBA Cockpit ( 可以直接输入 st04)，然后在 Performance 的目录下双击 Database, Buffer Pool 的标签内，可以看到当前数据库磁盘的读写状况。图1 磁盘 I/O 信息从图中我们可以看到磁盘物理平均读速度为 325ms，写速度为 745ms。分析磁盘物理读写速度反应了磁盘子系统的性能。一般情况下，磁盘读写速度应该小于 5ms，读速度一般要大于写速度，但在一些具有大量缓存的存储系统中，写速度可能会快于读速度。磁盘性能的优化已经超出了本文讨论的范围，这里只是提供一些基本的指导。缓冲池监控概念缓冲池是数据库单独开辟的一块存储区域，这片区域用来缓存从磁盘读出的包含数据表和索引的数据页。当数据第一次被检索出来以后便被暂时缓存在缓冲池中，当数据下次被访问时，数据库将直接从缓冲池中读取数据，这样减少了相对缓慢的磁盘 I/O *** 作。因此，缓冲池的配置对于数据库性能十分重要。在缓冲池中，目前还不支持存储大对象和长数据记录。反映缓冲池质量的一个重要性能指标是缓冲池命中率。缓冲池命中率指数据库管理器不需从磁盘读入页就能处理页请求的时间百分比。其计算方法为:缓冲池命中率 = (1 - (( 缓冲池数据物理读 + 缓冲池索引物理读 ) / ( 缓冲池数据逻辑读 + 缓冲池索引逻辑读 ) ) ) 100%另外两个重要性能指标是索引命中率和数据命中率。索引命中率反映了可以在缓冲池中找到的页面能够满足的对索引页的所有读请求所占的百分比。其计算方法为:索引命中率 = (1 - ( 缓冲池索引物理读 / 缓冲池索引逻辑读 ) ) ) 100%数据命中率说明了可以在缓冲池中找到的页面能够满足的对数据页的所有读请求所占的百分比。其计算方法为:数据命中率 = (1 - ( 缓冲池数据物理读 / 缓冲池数据逻辑读 ) ) ) 100%监控我们可以从三个级别来看缓冲池的质量，这三个层次分别是数据库级，缓冲池级，表空间级。在 SAP 系统中我们可以使用 DBA Cockpit 来查看不同级别的缓冲池质量。首先可以在数据库级查看缓冲池的质量，我们进入 SAP 的 DBA Cockpit，然后在 Performance 的目录下双击 Database, 在 Buffer Pool 的标签内，可以看到当前数据库总体的缓冲池质量。图2 缓冲池总体状况我们从图中可以看出，数据库缓冲池的总体命中率是 9981%，数据命中率为 9986%，索引命中率为 9970%。如果在 st04 中选中 Performance -> Buffer pools， 我们也可以在缓冲池级别看到命中率，如果一个数据库只有一个缓冲池，那么这个命中率与我们在数据库级别看到的命中率相同。图3 数据库级别缓冲池信息如果在 st04 中选中 Performance -> Tablespaces，我们就可以在表空间级别看到缓冲池的命中率。图4 表空间级别缓冲池信息分析缓冲池的理想命中率对于索引应该大于 90%, 对于数据应该大于 95%。要提高缓冲池的命中率，可以增加缓冲池的大小，也可以为不同类型数据分配不同缓冲池，可以为每个经常访问的具有自己的表空间的大型表使用一个缓冲池，也可以为一组小型表使用一个缓冲池。缓存监控概念数据库的缓存主要有包缓存 (Package Cache) 和编目录缓存 (Catalog Cache)。它们与数据库的查询性能息息相关。包缓存(Package Cache) :SQL 语句编译通常消耗的资源比较大，为了提高系统性能，动态 SQL 语句在被编译后一般存放于包缓存中。当用户下一次请求同一条 SQL 语句，就无需再次编译 SQL 语句。包缓存的质量一般通过包缓存命中率来衡量，它表明了包缓存的设置是否成功的避免了 SQL 语句的重新编译。其计算方法为:包缓存命中率 = (1 - ( 在包缓存中的插入次数 / 查询包缓存的次数 )) 100编目录缓存 (Catalog Cache):编目录缓存用来缓存系统编目录信息，如系统表，权限，系统存储过程。系统编目录的访问速度对于系统的性能有着十分重要的影响。在 DPF 环境下，系统编目录的访问速度至关重要。通过使用编目录缓存可以大大提高访问系统编目录的速度。编目录缓存质量一般通过编目录命中率来衡量，它表明了编目录缓存是否成功的避免了从磁盘中读取编目录信息。其计算方法为:包缓存命中率 = (1 - ( 在编目录缓存中的插入次数 / 查询编目录缓存的次数 )) 100监控我们进入 SAP 的 DBA Cockpit，然后在 Performance 的目录下双击 Database, 在 Cache 的标签内，可以看到当前数据库缓存的统计信息。图5 数据库缓存信息从图中我们可以看到编目录缓存的质量是 9993%，在图中的 quality 就是我们前面所说的命中率。当前数据库编目录缓存的大小为 10240KB，没有缓存溢出。在左边一栏，我们可以看到，包缓存的质量是 9764%，包缓存的大小为 62080KB，没有缓存溢出。分析包缓存的理想命中率应该大于 98%，用户通常不用关注包缓存的大小，如果 PCKCACHESZ 被设置为 automatic，其大小由 DB2 自动调节。编目录缓存的理想命中率也应该大于 98%，其大小应该保证编目录缓存不应该发生任何溢出。我们可以调整数据库配置参数 CATALOGCACHE_SZ 来改变编目录缓存大小，由于编目录缓存是从数据库堆中分配的，因此，在改变 CATALOGCACHE_SZ 变量的同时，应该注意到数据库堆的大小也会相应改变。排序监控概念DB2 在运行过程中时经常要做排序 *** 作。一般说来，在 OLTP 类型的数据库中，排序 *** 作通常少于 OLAP 类型的数据库环境。排序 *** 作通常会在三种情况下发生，第一种情况是数据的查询处理，比如 order by, group, 哈希连接，索引 *** 作，内存的表 *** 作等等。第二种是当我们载入 *** 作的对象是带有索引的表时，再载入 *** 作过程中就会涉及到对索引键的列表和排序，这样就会产生排序 *** 作。第三种情况发生在创建索引的时候。排序的效率因而直接影响到数据库的响应时间，我们必须对排序进行有效监控。监控我们进入 SAP 的 DBA Cockpit，然后在 Performance 的目录下双击 Database, 在 Sorts 的标签内，可以看到当前数据库的排序状况。图6 数据库排序状况可以从图中看出，共享排序堆的大小为 1676KB, 私有排序堆的大小为 1340KB。如果没有索引满足所取的行的要求顺序，或者 DB2 查询优化器认为排序的代价低于索引扫描，那么就需要在排序堆中进行排序。DB2 的排序分为私有排序和共享排序。私有排序发生在代理的私有代理内存中，而共享排序发生在数据库的数据库共享内存中。我们还可以看出，排序堆溢出次数 1174 次，总的排序次数为 310642 次。分析如果数据库分配的排序堆大小不够大，就会出现排序溢出的情况，这样就需要动用临时表空间来辅助排序的进行，由于临时表空间存在于磁盘，这将大大影响排序的速度。理想情况下，排序溢出率 ((Sort overflows 100) / Total sorts ) 不应该超过 1%。如果这个溢出率过高，那么数据库中很可能发生了大的排序，我们就需要调查出现过度排序的原因。在发现根源之前，一个简易的解决方案是增加 SORTHEAP 的大小。然而，这样做通常是治标不治本并且掩盖了真实的性能问题。比较彻底的解决方案应该是确定引起排序的 SQL 并更改该语句，或通过增加索引来避免或减少排序开销。并发性和锁的监控概念数据库的锁是数据库管理器用来控制应用程序并发访问数据库数据并且保证数据库数据的一致性的重要机制，数据库中行和表都可以上锁。数据库的锁在保证了数据库数据一致性同时也在一定程度上降低了数据库的响应速度。锁等待和死锁是影响数据库相应速度的重要因素，糟糕的应用程序设计和不合理的 SQL 查询计划的生成都会导致锁等待和死锁。锁升级 (Lock Escalation):一个锁通常作为一个记录存储在内存锁表中，锁表的大小可以由数据库自动调节。锁升级一般发生在锁的数量超过了数据库配置参数 MAXLOCKS 所指定的大小，为了减少锁的数量，数据库会把若干行一级的锁合并为表锁。这样数据库的并发性就会受到影响。监控我们进入 SAP 的 DBA Cockpit，然后在 Performance 的目录下双击 Database, 在 Locks and Deadlocks 的标签内，可以看到当前数据库的锁的状况。图7 数据库锁状况从图中可以看到，当前锁表的大小为 22144KB，已经使用了 94KB。锁等待的平均时间为 1040ms，没有锁升级和死锁被检测到。分析影响数据性能的有关锁的问题主要集中在锁等待，死锁和锁升级。这些问题的根源很可能是数据库应用的设计问题。因此，我们应该仔细调查造成死锁，锁等待和锁升级的应用程序，以及其用到的 SQL 语句。同时，在问题定位之前，我们也可以通过下面方法来解决数据库锁造成的性能问题。锁等待和死锁:如果要避免锁等待和死锁的问题我们需要注意数据库参数中的 DLCHKTIME 和 LOCKTIMEOUT 两个参数的设置。其中 DLCHKTIME 单位是毫秒，是 DB2 检查死锁的间隔时间，如果该值为 10000ms，则表明每隔 10 秒钟数据库会检查一下有无死锁存在，如有死锁，会选择回滚其中的某一个事务，让另外一个事务完成交易。LOCKTIMEOUT 单位是秒，是锁等待最长时间，超过该时间仍未获得锁，则返回错误。LOCKTIMEOUT 的默认值为 -1，这意味着锁等待时间无限大，一般不推荐这种设置。DLCHKTIME 时间通常要设得比 LOCKTIMEOUT 时间小一些，否则还未发现死锁，就会返回锁等待超时错误 (SQL0911N 返回码 68) 。锁升级:要避免锁升级，我们应该正确设置数据库参数 LOCKLIST 和 MAXLOCKS。LOCKLIST 表明分配给锁表的内存大小。每个数据库都有一个锁表，锁表包含了并发连接到该数据库的所有应用程序所持有的锁。MAXLOCKS 定义了应用程序可以占有锁表空间的百分比，当一个应用程序所使用的锁表百分比达到 MAXLOCKS 时，数据库管理器会升级这些锁，用表锁代替行锁，从而减少列表中锁的数量。我们一般可以通过增加锁表大小的方法解决锁升级问题。日志性能监控概念DB2 事务日志对于恢复来说极其重要。它们记录对数据库对象和数据所做的更改。在 DB2 中数据和索引的改变都会先被写入日志缓冲区，保证对数据所做的修改在记录到数据库之前，总是被具体化为日志文件。日志缓冲区的数据由日志处理器写入磁盘。在下列情况下，查询处理必须等待日志数据写入磁盘后才能进行: 事务提交时。在将相应数据页写入磁盘之前，因为 DB2 使用预写日志记录。预写日志记录的好处是当执行 COMMIT 语句完成事务之后，并非所有更改的数据和索引页都需要写入磁盘。 在元数据更改(一般通过执行 DDL 语句产生的)之前。 日志缓冲区已满。DB2 以这种方法管理向磁盘写入日志数据的目的是尽可能地缩短处理延迟时间。在存在许多较小的并发事务的环境中，许多处理延迟是由 COMMIT 造成的，因为它必须等待日志数据写入磁盘后才能进行。因此，日志处理器进程频繁地将少量日志数据写入磁盘会造成大量处理延迟，另外一些延迟是由日志 I/O 开销造成的。监控我们进入 SAP 的 DBA Cockpit，然后在 Performance 的目录下双击 Database, 在 Logging 的标签内，可以看到当前数据库日志的状况。图8 数据库日志状况我们在图中可以看到日志文件以及日志缓冲区的情况。包括日志文件的数量，大小，数据库使用的日志空间以及可用日志空间的大小。还可以看到日志缓冲区的情况，当前日志缓冲区的命中率为 100%。分析由于数据库中的处理必须等待日志数据写入磁盘才能进行，日志文件的读写速度对数据库的响应速度也会产生很大影响。因此，应该把日志文件放到速度比较快的磁盘上，以减少磁盘 I/O 开销。日志文件写入的性能可以通过平均写时间来观察。另外，我们可以通过调整数据库配置参数 LOGBUFSZ 来指定日志缓冲区的大小。如果数据库对于日志磁盘有相当多的读 *** 作，或者希望有较高的磁盘利用率。一般来说，如果日志缓冲区的命中率小于 98%，那么可以增加这个缓冲区的大小以提高命中率。当增加这个参数的值时，也要考虑 DBHEAP 参数，日志缓冲区使用的空间是 DBHEAP 参数所定义的内存空间的一部分。数据库统计信息监控概念数据库的统计信息反映了表及其相关索引的物理特点。统计信息主要包含: 表信息:表的行数，使用的数据页，溢出的行数，列的平均长度，列的最大最小值等。 索引信息:索引条目的数量，索引所关联列的不同值的数量，索引的层数等。这些信息被数据库查询优化器用来生成查询计划。好的访问计划对于 SQL 语句的快速执行至关重要。我们需要想办法保证统计信息准确地反映了当前数据库的状况。由于数据库的表和索引总是随着数据库处理各种更新请求而不断发生变化的，因此，总会出现统计信息过时，而不能正确反映数据库数据现状的情况。这时，数据库查询优化器生成的查询计划可能不是最优的，这将大大影响数据库的查询性能。我们应该经常检查数据库的统计信息是否为最新的，并及时更新统计信息。SAP 系统为我们提供了监控和执行统计信息收集的方法。监控我们进入 SAP 的 DBA Cockpit，然后在 Performance 的目录下双击 Tables, 在 Table 列表中双击要监控的表，在 Table 的标签中，我们可以看到当前表的基本信息。这时，如果我们点击 Count 按钮，就会看到统计信息的质量。图9 表的统计信息状况从图中我们看到，表的当前行数为 27，Deviation 为 8%。分析如果我们监控到一个表的 Deviation 超过了 15%，我们就应该重新收集这个表的统计信息。在 SAP 中我们可以选择手动收集统计信息。我们也可将系统配置成自动收集统计信息，这样大大减少了系统手动维护的工作量。自动统计信息收集通常每隔 2 个小时触发一次，它会自动选择在 24 小时之内没有收集过统计信息的持久的基表。如果 SAP 系统进行 Client Copy 或在 BI 表中加载大量数据，由于这些 *** 作在短时间就可以改变表的数据状况及分布，因此会导致统计信息的过时。在 DB2 V95 中，为了解决这个问题，提供了一种 RTS (Real Time Statistics) 的特性，该特性可以允许在查询被处理并优化前对表的统计信息进行收集或采样，如果优化器认为重新收集统计信息比用过时的统计信息进行查询的速度快，那么会在处理该查询之前重新收集表的统计信息，从而达到实时收集统计信息的目的。我们一般需要将数据库配置参数 AUTO_STMT_STATS 设为 ON 来开启 RTS 特性，但在 SAP 系统中，RTS 已经是默认设置，我们无需进行任何改变。回页首结束语本文从数据库问题检测的一般思路和方法论出发，介绍了如何通过 SAP 系统对 DB2 的性能进行监控。

打补丁的时候应该会提示是否应用到所有的实例，你可以为那个需要sp1的软件装一个有sp1的实例就好了。

实际上打补丁或是升级sql软件还是会对数据文件有一定影响的，你把2000的数据库挂到2005上用过后，再要挂回到2000上，数据库文件就不识别了。当总体来说是不影响用的。放心吧。

微软连这都要搞飞机，早就被人告了。

Oracle数据库由数据库文件、日志文件、控制文件组成。

Oracle数据库12c 引入了一个新的多承租方架构，使用该架构可轻松部署和管理数据库云。此外，一些创新特性可最大限度地提高资源使用率和灵活性，如Oracle Multitenant可快速整合多个数据库，而Automatic Data Optimization和Heat Map能以更高的密度压缩数据和对数据分层。

这些独一无二的技术进步再加上在可用性、安全性和大数据支持方面的主要增强，使得Oracle数据库12c 成为私有云和公有云部署的理想平台。

扩展资料：

Oracle数据库升级注意事项：

1、备份配置参数

数据库升级前的配置参数要备份，如PGA大小。这样数据库升级后还可以升级前的配置，而不至于使用安装升级时的默认配置。

2、检查版本兼容

确认数据库升级后是否对生产环境上的代码有影响，如果发现一处有影响，则要在全部范围内检查类似的情况。

3、客户端同步升级

同时升级开发者本地环境或应用程序的数据库客户端升级到与数据库服务器相同版本。

4、确保程序正常运行

数据库升级后确保升级后的数据库不会对连接该库的应用程序有影响。

以上就是关于SQLServer数据库内存会不断增加的问题分析全部的内容，包括:SQLServer数据库内存会不断增加的问题分析、程序与数据库版本不一致，请进行系统库升级，以下是版本信息：、如何在 SAP 系统中监控和分析 DB2 UDB 性能等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！