加点数据库授权时候，如果销售授权是DMP授权文件，新加点授权是SCP授权文件，DMP授权文件和SCP授权文件无法合并。这种情况下，需要走商务流程，需要将原来的DMP授权文件，转换为SCP授权文件。需要储运协助授权文件转换。 无 无 无 1、发送邮件，给石龙奇(66493)、黄建正(33159)、周磊-SDDC(56341)，周磊备案后，表示授权文件可转换。 邮件中附带：客户名称：xxxxx，订单ID：xxxxxxx，KEY ID：xxxxxxx，SCP版本号 2、储运黄建正(33159)协助，DMP授权文件转换成SCP授权文件，同类型同配额转换，比如：MySQL授权转MySQL授权等。   FAQ： 1、授权文件什么时候需要转换？ 已生效授权是DMP授权文件，需要新加点。可通过DMP管理平台查看或云图查看。 a、DMP管理平台查看，登录DMP控制台-系统设置-序列号。 b、或者登录云图，输入客户名单和订单号，确认历史订单，有数据库管理平台订单。 新的授权文件如何生效？ 获取lic的授权文件后，登录SCP控制台【系统管理】-【平台授权】更新序列号，导入授权文件或者单独更新具体授权项。并在【授权服务】下发创建DMP服务授权。        

在Linux 7 系统中需要自定义网卡名称，可以禁用可预测命名规则，在/etc/default/grub并加入“net.ifnames=0 biosdevname=0 ”到GRUBCMDLINELINUX变量实现。     Linux 7 默认使用预测命名规则。 1、修改/etc/default/grub 文件 #在 GRUB_CMDLINE_LINUX 这一项中后面添加 net.ifnames=0 biosdevname=0 vim /etc/default/grup 原始内容> GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet" 新的内容> GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap net.ifnames=0 biosdevname=0 rhgb quiet"   2、执行查看网卡命令查看网卡的MAC地址并记录 [root@111 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether fa:16:3e:18:f9:7c brd ff:ff:ff:ff:ff:ff inet 192.168.80.147/24 brd 192.168.80.255 scope global dynamic eth0 valid_lft 82832sec preferred_lft 82832sec inet6 fe80::f816:3eff:fe18:f97c/64 scope link valid_lft forever preferred_lft forever   3、新建网卡命名规则文件需要修改的参数是 ATTR{address} 和 NAM，E#ATTR{address}是原mac地址（小写字母） ；NAME是修改后的网卡名字 vim /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM"net", ACTION"add", DRIVERS"?*", ATTR{address}"fa:16:3e:18:f9:7c", ATTR{type}"1", KERNEL"eth*", NAME="ens34"   4、添加/修改网卡配置文件 vim /etc/sysconfig/network-scripts/ifcfg-ens34 TYPE="Ethernet" BOOTPROTO="dhcp" DEFROUTE="yes" NAME="ens34" DEVICE="ens34" ONBOOT="yes" 5、更新 GRUB 配置文件，重启生效 grub2-mkconfig -o /boot/grub2/grub.cfg reboot          

当 SQL Server 数据库引擎实例未运行、服务器名称键入错误或者存在网络问题或防火墙时，通常会发生“超时时间已到”错误。   在 SQL Server Management Studio 中，此错误显示为： “无法连接到 <服务器名>。” “超时时间已到。在操作完成之前超时时间已过或服务器未响应。（Microsoft SQL Server，错误: -2）”   在 sqlcmd 中，可能出现的超时错误包括： “SQL 网络接口: 定位指定的服务器/实例时出错” “Sqlcmd: 错误: Microsoft SQL Server Native Client : 客户端无法建立连接。” “Sqlcmd: 错误: Microsoft SQL Server Native Client : 登录超时时间已到。” “无法与 SQL Server 建立连接” “建立与服务器的连接时出错。当连接到 SQL Server 时，此故障可能会因为 SQL Server 在默认设置下不允许进行远程连接而引发的。” * 键入的服务器名称不正确。 * 服务器中的 SQL Server 服务未运行。 * 数据库引擎实例的 TCP/IP 端口被防火墙阻塞。 * 数据库引擎由于已被更改或者不是默认实例而不侦听端口 1433，并且没有运行 SQL Server Browser 服务。 * SQL Server Browser 服务正在运行，但 UDP 端口 1434 被防火墙阻塞。 * 客户端和服务器未配置为使用相同的网络协议。 * 网络无法将服务器名称解析为 IP 地址。可使用 PING 程序对此进行测试。 * 无法使用 IP 地址连接到网络。可使用 PING 程序对此进行测试。 键入的服务器名称不正确。 应使用正确的服务器名称，然后重试。   服务器中的 SQL Server 服务未运行。 应启动 SQL Server 数据库引擎实例。   数据库引擎实例的 TCP/IP 端口被防火墙阻塞。 应将防火墙配置为允许访问数据库引擎。   数据库引擎由于已被更改或者不是默认实例而不侦听端口 1433，并且没有运行 SQL Server Browser 服务。 要么启动 SQL Server Browser 服务，要么指定 TCP/IP 端口号进行连接。   SQL Server Browser 服务正在运行，但 UDP 端口 1434 被防火墙阻塞。 将防火墙配置为允许访问服务器上的 UDP 端口 1434，或者连接指定 TCP/IP 端口号。   客户端和服务器未配置为使用相同的网络协议。 使用 SQL Server 配置管理器，确认服务器和客户端计算机至少有一个通用的启用协议。   网络无法将服务器名称解析为 IP 地址。可使用 PING 程序对此进行测试。 修复网络上的计算机名称解析问题，或者使用服务器的 IP 地址连接。这不是 SQL Server 问题。有关帮助，请参阅 Windows 文档或与网络管理员联系。   无法使用 IP 地址连接到网络。可使用 PING 程序对此进行测试。 修复网络上的 TCP/IP 问题。这不是 SQL Server 问题。有关帮助，请参阅 Windows 文档或与网络管理员联系。          

使用 TCP/IP 连接到 SQL Server 时，可能会出现此错误。 该错误出现时可能具有以下格式： TCP_PROV: 现有连接被远程主机强行关闭。 访问接口编号: 7，错误: 10054，错误消息:“TCP 访问接口: 现有连接已被远程主机强行关闭 ” 未处理的异常: 在向服务器发送请求时发生传输级错误。(访问接口: TCP 访问接口，错误: 0 - 现有连接已被远程主机强行关闭。)     客户端已与不支持的 SQL Server Native Client 版本连接。 发生故障的网络硬件正在删除部分 TCP 通信。 客户端已与不支持的 SQL Server Native Client 版本连接。 将客户端计算机更新为 SQL Server Native Client 的服务器版本。   发生故障的网络硬件正在删除部分 TCP 通信。 使用网络监视程序分析 TCP SYN、ACK 和 FIN 消息。          

因密码或用户名错误而使身份验证失败并导致连接尝试被拒时，类似下面的消息将返回到客户端：“用户 '<user_name>' 登录失败”。（Microsoft SQL Server，错误: 18456）”。 返回到客户端的其他信息有： “用户 '<user_name>' 登录失败。（.Net SqlClient 数据访问接口）” ------------------------------ “服务器名称: <computer_name>” “错误号: 18456” “严重性: 14” “状态: 1” “行号: 65536” 也可能返回以下消息： “消息 18456，级别 14，状态 1，服务器 <computer_name>，第 1 行” “用户 '<user_name>' 登录失败。”     检查返回信息中“状态”数值，确认失败原因。 为了增强安全性，返回到客户端的错误消息有意隐藏身份验证错误的本质。但是，在 SQL Server 错误日志中，对应的错误包含映射到身份验证失败条件的错误状态。将错误状态与以下列表进行比较以确定登录失败的原因。 状态｜说明 2 ｜用户 ID 无效。 5 ｜用户 ID 无效。 6 ｜尝试同时使用 SQL Server 身份验证与 Windows 登录名。 7 ｜登录已禁用，密码不正确。 8 ｜密码不正确。 9 ｜密码无效。 11 ｜登录有效，但服务器访问失败。 12 ｜登录是有效的登录，但服务器访问失败。 18 ｜必须更改密码。 存在其他错误状态，并表示一个意外的内部处理错误。 在此示例中，身份验证错误状态为 8，这指示密码不正确。 日期来源消息 2023-12-05 20:12:56.34 登录 错误: 18456，严重性: 14，状态: 8。 2023-12-05 20:12:56.34 登录 用户 '<user_name>' 登录失败。[CLIENT: <IP 地址>]            

连接到 SQL Server 的客户端如果在 SQL Server 上未启用命名管道支持时连接到该服务器（即使可以使用其他协议，如 TCP/IP），可能会遇到此命名管道错误。 如果服务器上未启用命名管道，则拒绝客户端试图使用命名管道进行连接。以下两种情况下会出现此错误： 客户端试图只使用命名管道进行连接，而服务器上未启用命名管道协议。 客户端试图使用任何可用的协议进行连接，但在客户端协议顺序中，named pipes 列在 TCP 之前。 错误文本 named pipes 提供程序：在管道的另一端没有进程。 Microsoft SQL Server Native Client：通信链接失败。 Microsoft SQL Server Native Client：在与服务器建立连接时出现错误。当连接到 SQL Server 时，此故障可能是因为 SQL Server 在默认设置下不允许进行远程连接而引发的。     客户端试图使用 named pipes 进行连接，而服务器没有配置为允许使用 named pipes 进行远程连接。 应使用 TCP/IP 进行连接，或使用 SQL Server 配置管理器通过 named pipes 进行远程连接。   客户端协议顺序是在尝试 TCP 协议之前试图使用 named pipes 协议进行连接，而服务器上未启用 named pipes。 应在客户端计算机上使用 SQL Server 配置管理器，在协议顺序列表中将 TCP 移动到 Named Pipes 之前。 客户端试图使用 named pipes 进行连接，而服务器没有配置为允许使用 named pipes 进行远程连接。 应使用 TCP/IP 进行连接，或使用 SQL Server 配置管理器通过 named pipes 进行远程连接。   客户端协议顺序是在尝试 TCP 协议之前试图使用 named pipes 协议进行连接，而服务器上未启用 named pipes。 应在客户端计算机上使用 SQL Server 配置管理器，在协议顺序列表中将 TCP 移动到 Named Pipes 之前。        

作为系统管理员可以重新获得对 SQL Server 数据库引擎的访问权限。 系统管理员可能会由于下列原因之一失去对 SQL Server 实例的访问权限：  作为 sysadmin 固定服务器角色成员的所有登录名都已经被误删除。  作为 sysadmin 固定服务器角色成员的所有 Windows 组都已经被误删除。  作为 sysadmin 固定服务器角色成员的登录名用于已经离开公司或者无法找到的个人。  sa 帐户被禁用或者没有人知道密码。     误删了所有超级管理员权限和忘记了密码。 可以让您重新获得访问权限的一种方法是重新安装 SQL Server 并将所有数据库附加到新实例。这种解决方案很耗时，并且若要恢复登录名，可能还需要从备份中还原 master 数据库。 如果 master 数据库的备份较旧，则它可能未包含所有信息。如果 master 数据库的备份较新，则它可能与前一个实例具有同样的登录名；因此管理员仍将被锁定。   使用 -m 或 -f 选项在单用户模式下启动 SQL Server 的实例。计算机的本地 Administrators 组的任何成员都可以随后作为 sysadmin 固定服务器角色的成员连接到 SQL Server 实例。   注意：在单用户模式下启动 SQL Server 实例时，请首先停止 SQL Server Agent 服务。否则，SQL Server 代理可能会首先连接，并阻止您作为第二个用户连接。   当您将 -m 选项与 sqlcmd 或 SQL Server Management Studio 一起使用时，可以将连接限制为指定的客户端应用程序。 例如，-m"sqlcmd" 将连接限制为单个连接并且该连接必须将自身标识为 sqlcmd 客户端程序。 当您正在单用户模式下启动 SQL Server 并且未知的客户端应用程序正在占用这个唯一的可用连接时，使用此选项。 若要通过 Management Studio 中的查询编辑器进行连接，请使用 -m"Microsoft SQL Server Management Studio - Query"。          

导致 SQL Server 数据库处于 SUSPECT 状态的重做、撤消或恢复操作期间的错误。这样的错误包括 3313（日志重做错误）、3314（日志撤消错误）、3414（阻止数据库重新启动的恢复错误）以及 3456（有关记录的事务的重做错误）。 重做、撤消或恢复错误会导致数据库处于 SUSPECT 状态，因为主文件组（可能还有其他文件组）可疑，可能已损坏。无法使用数据库，需要用户执行操作来解决问题。 注意：如果对于 tempdb 发生此错误，则 SQL Server 实例关闭。     重做、撤消或恢复错误也可能是由当您每次尝试启动数据库时发生的暂时或永久性故障导致的。 有关错误 3313、3314、3414 或 3456 出现原因的信息，请检查 Windows 事件日志以了解有关指示特定故障的先前错误。相应的用户操作取决于 Windows 事件日志中的信息是否指示该 SQL Server 错误由暂时或永久性故障导致。 注意：当遇到任何此类错误状况时，SQL Server 通常在 SQL Server LOG 文件夹中生成三个文件。SQLDumpnnnn.txt 文件包含与故障相关的高级诊断信息，包括有关事务的详细信息和遇到问题的页面。 暂时性故障： 通过执行以下 ALTER DATABASE Transact-SQL 语句，尝试使数据库联机： ALTER DATABASE SET ONLINE; 为了确定恢复是否成功完成以及数据库是否已联机，请查看 SQL Server 错误日志和 sys.databases 目录视图。 如果数据库已联机，则执行 DBCC CHECKDB 语句以验证数据库是否一致。 DBCC CHECKDB [ [ (database_name | database_id | 0 [ , NOINDEX | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ] ) ] [ WITH { [ ALL_ERRORMSGS ] [ , EXTENDED_LOGICAL_CHECKS ] [ , NO_INFOMSGS ] [ , TABLOCK ] [ , ESTIMATEONLY ] [ , { PHYSICAL_ONLY | DATA_PURITY } ] } ] ]     永久故障： 在 SQL Server 错误日志中，查找您正在解决的错误（3313、3314、3414 或 3356）并查看它之前的消息，以确定您是否可以手动纠正这些错误。如果您可以纠正更早的错误，则执行以下过程之一：还原和验证数据库（建议的过程），如下所示： 尝试执行结尾日志备份。 BACKUP LOG 数据库名称 TO < 备份设备> WITH CONTINUE_AFTER_ERROR 使用 RESTORE …WITH NORECOVERY 语句从完整数据库备份还原数据库，并且可以选择后跟差异数据库备份。 如果数据库使用完整恢复模式，则使用 RESTORE LOG … WITH NORECOVERY 应用在将完整或差异备份还原到故障点之后执行的所有事务日志备份。 当您将数据库还原到尽可能接近故障点时，通过使用 RESTORE DATABASE <数据库名称> WITH RECOVERY 恢复数据库。 在数据库联机后，运行 DBCC CHECKDBTransact-SQL 语句以验证数据库是否一致。 通过使用在本节前面介绍的针对临时性错误的步骤，尝试使数据库联机。 使用紧急模式，如下所示： 通过执行以下 ALTER DATABASE语句，将数据库转换到 EMERGENCY 状态： ALTER DATABASE SET EMERGENCY; 检查 ALTER DATABASE 语句和 SQL Server 错误日志的输出。 在 sys.databases 目录视图中检查数据库的状态。 使用 DBCC CHECKDB 语句针对数据库执行一致性检查，以了解损坏的性质和程度。 在评估来自 DBCC CHECKDB 的输出时，可以选择使用 REPAIR_ALLOW_DATA_LOSS 选项执行 DBCC CHECKDB。 注意：在使用此选项之前，在 SQL Server 联机丛书的 DBCC CHECKDB (Transact-SQL) 主题中仔细查看有关在数据库紧急模式下修复错误的信息。注意：有关应对与错误 3313、3314、3414 或 3356 相关的硬件问题的信息，请参阅 MSSQLSERVER_824。 避免此错误的步骤 为了避免再次遇到这种情况，请执行以下操作：检查 SQL Server 错误日志和 Windows 事件日志，以了解可能导致此错误的任何系统范围的问题。若要排除产品中导致此状况的任何已知问题，请应用您的 SQL Server 版本的最新累积更新。          

本文对已满事务日志可以采取的几种应对措施，并就以后如何避免出现已满事务日志给出建议。 如果事务日志已满，则 SQL Server 数据库引擎会发出 9002 错误。 当数据库联机或恢复时，日志可能会满。如果数据库联机时日志已满，则数据库保持联机状态，但是只能进行读取而不能更新。 如果恢复过程中日志已满，则数据库引擎将数据库标记为 RESOURCE PENDING。不管哪种情况，都需要用户执行操作才能使日志空间可用。   注意：一般来说，事务日志用尽磁盘空间后，仍可以在只读模式下访问数据库。但是，启用快照隔离级别时，如果您正在删除堆（没有聚集索引的表）中的行且事务日志在虚影行的日志记录持久化前填充，则数据库将脱机。如果出现这种情况，数据库将自动重新启动，进行完全恢复后再联机。       正确应对已满事务日志在某种程度上取决于导致日志已满的情况。若要在给定情况下查找阻止日志截断的原因，请使用 sys.database 目录视图的 log_reuse_wait 列和 log_reuse_wait_desc 列。 有关延迟日志截断的因素的说明，请参阅可能延迟日志截断的因素。 参考：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms345414(v=sql.105)   提示：如果数据库在恢复过程中出现 9002 错误，则在解决此问题后，可使用 ALTER DATABASE database_name SET ONLINE 恢复数据库。 应对已满事务日志的备选方法包括： * 备份日志。 * 释放磁盘空间以便日志可以自动增长。 * 将日志文件移到具有足够空间的磁盘驱动器。 * 增加日志文件的大小。 * 在其他磁盘上添加日志文件。 * 完成或取消长时间运行的事务。   下列部分介绍了这些备选方法。请选择最适用于您情况的响应。 1、备份日志 在完整恢复模式或大容量日志恢复模式下，如果最近尚未备份事务日志，则请立即进行备份以免发生日志截断。如果从未备份日志，则必须创建两个日志备份，以允许数据库引擎将日志截断到上次的备份点。截断日志可释放空间以供新的日志记录使用。若要防止日志再次填满，请经常执行日志备份。   参考：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms179478(v=sql.105)   2、释放磁盘空间 您可以通过删除或移动其他文件的方法来释放包含数据库事务日志文件的磁盘驱动器上的磁盘空间。释放磁盘空间后，恢复系统将自动扩大日志文件。   3、将日志文件移至其他磁盘 如果在当前包含日志文件的驱动器上无法释放足够的磁盘空间，请考虑将该文件移至空间充足的其他驱动器上。 提示：日志文件决不要放在压缩文件系统中。 移动日志文件：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms189133(v=sql.105)   4、增加日志文件的大小 如果日志磁盘上具有可用空间，则可以增加日志文件的大小。日志文件的最大大小是每个日志文件 2 TB。 如果禁用自动增长，数据库处于联机状态，并且磁盘上有足够的可用空间，则可采用以下方法之一： 手动增加文件大小以生成单个增量。 使用 ALTER DATABASE 语句启用自动增长以针对 FILEGROWTH 选项设置非零增量。 注意：不管哪种情况，如果已达到当前大小限制，则应增加 MAXSIZE 值。   5、在其他磁盘上添加日志文件 使用 ALTER DATABASE <database_name> ADD LOG FILE，向具有足够空间的其他磁盘上的数据库中添加新日志文件。 添加和删除数据文件和事务日志文件：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms191433(v=sql.105) 如何向数据库中添加数据或日志文件：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms189253(v=sql.105)   6、完成或取消长时间运行的事务。 标识和管理长时间运行的事务：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms366331(v=sql.105)          

在恢复过程中，SQL Server 数据库引擎可能需要更多的磁盘空间保存数据文件。如果操作过程中没有足够的磁盘空间，则数据库引擎会发出 1101 或 1105 错误（分别取决于它无法为区分配空间或为对象分配空间）。 如果数据库联机时磁盘已满，则数据库保持联机状态，但是不能插入数据。 如果恢复过程中磁盘已满，则数据库引擎将数据库标记为“资源挂起”。 不管哪种情况，都需要用户执行操作才能使磁盘空间可用。     磁盘空间不足。 下列操作之一可能会将空间用于文件组： 释放已满磁盘上的磁盘空间。 将数据文件移到另一个磁盘。 在其他磁盘上添加文件。 启用自动增长。   注意：如果数据库恢复过程中出现错误，则必须在解决问题后恢复数据库。   1、释放已满磁盘上的磁盘空间 在错误消息中提及的文件组内包含文件的磁盘上，通过删除所有不需要的索引或表来释放磁盘空间。释放磁盘空间允许文件组中的文件增长。   2、将数据文件移到另一个磁盘 参考：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms189133(v=sql.105)   3、在其他磁盘上添加文件 (Transact-SQL) 使用 ALTER DATABASE <数据库名称> ADD FILE TO FILEGROUP <文件组名>，将更多的文件添加到其他磁盘上的文件组。 参考：https://learn.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008-r2/ms191433(v=sql.105)   4、增加文件大小 注意：不管哪种情况，如果已达到当前大小限制，则应增加 MAXSIZE 值。 如果禁用自动增长，数据库处于联机状态，并且磁盘上有足够的可用空间，则可采用以下方法之一： 手动增加文件大小以生成单个增量。 使用 ALTER DATABASE 语句启用自动增长以针对 FILEGROWTH 选项设置非零增量。   5、恢复数据库 如果数据库在恢复过程中用完了磁盘空间，则可使用 ALTER DATABASE <数据库名称> SET ONLINE 恢复数据库联机。          

客户反馈备份失败，因为使用第三方的备份软件，从备份的报错信息来看，报 ORA-00234: error in identifying or opening snapshot or copy control file     首先排查是否是由于带库引起备份问题，尝试直接在磁盘上备份，执行如下命令   run { allocate channel c1 type disk; backup current controlfile format '/tmp/db_ctl_%d_%T_%s_%p.bak'; release channel c1; }   执行后发现报同样报错，该报错指向控制文件快照文件。 查询 RMAN 相关文件快照路径，发现控制文件快照路径为ASM 磁盘组，未写文件名。 RMAN的“SNAPSHOT CONTROLFILE NAME”未指定正确的名称。 修改控制文件快照路径 RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+oradata/snapcf_orcl.f';   调整后发现备份恢复正常 注意: 1. 控制文件的快照文件必须能够被所有节点的数据实例访问到，并且必须放在共享的位置。否则，使用RMAN进行备份控制文件的时候会报错 2. 建议对参数调整后，建议经各方面测试验证无误后再修改          

业务系统整体卡慢，操作系统几乎无法操作，内存使用率高，存在swap进程交换内存，sar观察swap扫描频繁。     1、 检查OS资源： * 系统大量使用SWAP，说明系统内存不足。 * cached占用说明数据库通过“经系统IO”，可能会因缓存文件导致内存过度消耗。   通过系统负载可以看到全天（特别是凌晨）存在大量的内存交换扫描，可见系统内存不足，开始使用SWAP 。   2、DB检查； 通过AWR报告观察数据库缓存命中率低，约为67% ，TP环境不应低于90%，建议将SGA内存配置到160GB以上。     PGA的内存消耗达到配置的上限，导致内存分配等待，建议扩大PGA到20     由于数据库未合理限制内存使用，导致操作系统内存不足，Swap交换内存时系统卡慢，几乎无法使用。 1、本例需扩大虚拟机内存到220GB 以上（SGA 160G + PGA 20G + OS预留和缓存 32GB）。 2、配置使用大页内存（HugeTabe），避免会话较多时/内存页过多，导致页表（TablePage）占用过多内存。 3、建议将数据库的文件系统IO调整为setall （避免经系统缓存IO，导致OS Cache大量消耗内存） 、 SGA调整为160G 、PGA 调整为20G 。            

报错信息：ERROR 1264 (22003): Out of range value for column % 告警事件：MySQL数据库自增主键使用率超过阈值   查看当前数据库中自增主键使用率 SELECT t.TABLE_SCHEMA AS 'database_name', t.TABLE_NAME AS 'table_name', c.COLUMN_TYPE AS 'primary_type', t.AUTO_INCREMENT AS 'auto_column', CONCAT( t.AUTO_INCREMENT / ( CASE DATA_TYPE WHEN 'tinyint' THEN IF ( COLUMN_TYPE LIKE '%unsigned', 255, 127 ) WHEN 'smallint' THEN IF ( COLUMN_TYPE LIKE '%unsigned', 65535, 32767 ) WHEN 'mediumint' THEN IF ( COLUMN_TYPE LIKE '%unsigned', 16777215, 8388607 ) WHEN 'int' THEN IF ( COLUMN_TYPE LIKE '%unsigned', 4294967295, 2147483647 ) WHEN 'bigint' THEN IF ( COLUMN_TYPE LIKE '%unsigned', 18446744073709551615, 9223372036854775807 ) END / 100 ),'%') AS ratio FROM information_schema.TABLES t INNER JOIN information_schema.`COLUMNS` c ON t.TABLE_SCHEMA = c.TABLE_SCHEMA AND t.TABLE_NAME = c.TABLE_NAME WHERE t.AUTO_INCREMENT IS NOT NULL AND c.COLUMN_KEY = 'PRI' AND c.DATA_TYPE LIKE '%int' ORDER BY ratio DESC; 查询结果如下： +---------------+------------+------------------+-------------+-----------+ | database_name | table_name | primary_type | auto_column | ratio | +---------------+------------+------------------+-------------+-----------+ | test | z_bak1 | int(11) | 2147483647 | 100.0000% | | sbtest1 | sbtest1 | int(11) | 1000001 | 0.0466% | | sbtest1 | sbtest2 | int(11) | 1000001 | 0.0466% | | sbtest1 | sbtest3 | int(11) | 1000001 | 0.0466% | | sbtest1 | sbtest4 | int(11) | 1000001 | 0.0466% | | mysql | time_zone | int(10) unsigned | 1 | 0.0000% | | test | z | int(11) | 16 | 0.0000% | +---------------+------------+------------------+-------------+-----------+ 7 rows in set (0.08 sec) int类字段类型有对应的上限值，当达到上限之后就无法继续增加。范围如下: 字段类型 signed unsigned tinyint 127 255 smallint 32767 65535 mediumint 8388607 16777215 int 2147483647 4294967295 bigint 9223372036854775807 18446744073709551615   int类字段从小到大排序为：tinyint --> smallint --> mediumint --> int --> bigint，其中unsigned范围是signed的两倍。 当发现ratio大于90%时，判断字段类型，如果不是bigint unsigned可以采取如下措施（注意：危险操作，请谨慎处理！！！） ALTER TABLE <table_name> MODIFY id bigint unsigned AUTO_INCREMENT; 若发现字段类型已经是bigint unsigned，且ratio接近100%，甚至语句已经开始报错ERROR 1264 (22003): Out of range value for column %时，需要判断当前表中是否存在大量的间隙，命令如下： select concat(count(distinct <primary_key>)/18446744073709551615/100,'%') hollow_ratio from <table_name>; 注意，此语句会进行全表扫描，会对当前数据库系统造成一定的性能影响。 如果查询结果holow_ratio占比低于50%，且自增字段不作为业务关联键，可以按如下步骤重新按需生成自增主键：以表 t 为例，其表结构如下： Table: z Create Table: CREATE TABLE `z` ( `id` int(11) NOT NULL AUTO_INCREMENT, `b` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `b` (`b`) ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8 重新按需生成自增值（注意：危险操作，请谨慎处理！！！） create table t_new like t; insert into t_new(id,b) select null,b from t ; rename table t to t_tmp; rename table t_new to t; 注意：此过程会全表扫描表 t，并将其插入到表t_new中，在通过rename操作使其表名对调。过程中会产生大量的IO，建议与业务部门沟通后再进行操作。 理论上不存在大量的间隙的情况下，查询结果holow_ratio很难达到上限，实际场景中真有发现，建议分库分表。 也可以删除主键重建（注意：危险操作，请谨慎处理！！！） ALTER TABLE `t` DROP COLUMN `id`, DROP PRIMARY KEY; ALTER TABLE `t` ADD COLUMN `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT FIRST, ADD PRIMARY KEY (`id`);                                

数据库接入管理异常，平台检测到提供的客户端数据库账号不满足权限要求   （1）登录云端智能大脑–数据库智能诊断–数据库接入管理，查看账号所需权限 （2）点击编辑--开始测试--查看原因，页面对每类数据库所需权限均有提示   情况一：数据库类型为MySQL数据库 （1）登录数据库 mysql -u<username> -p<password> -S <sock> （2）检查权限，用户所需的权限为：PROCESS, SELECT, REPLICATION CLIENT, EXECUTE 等权限 mysql> show grants for 'test'; +-------------------------------------------------------------------------+ | Grants for test@% | +-------------------------------------------------------------------------+ | GRANT SELECT, PROCESS, EXECUTE, REPLICATION CLIENT ON *.* TO 'test'@'%' | +-------------------------------------------------------------------------+ （3）按照指引，添加权限或重新添加账号 命令参考： CREATE USER '{user}'@'%' IDENTIFIED BY '{password}'; GRANT PROCESS, SELECT, REPLICATION CLIENT, EXECUTE ON *.* TO '{user}'@'%'; （4）点击进入【数据库接入管理】→【编辑】→【连通性测试】→【开始测试】，验证账号权限是否正确。   情况二：数据库类型为Oracle数据库 （1）点击【数据库接入管理】→ 【编辑】，查看账号所需权限和创建指引。 （2）切换到oracle用户，使用sysdba登录数据库 # su - oracle # sqlplus / as sysdba （3）检查用户权限，所需的权限为：SELECT ANY DICTIONARY, ADVISOR, CREATE SESSION, EXECUTE ON DBMS_WORKLOAD_REPOSITORY ，建议包含 ALTER SYSTEM 权限。 SQL> set line 1000 SQL> SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE = 'TEST'; GRANTEE PRIVILEGE ADM ------------------------------ ---------------------------------------- --- TEST ALTER SYSTEM NO TEST ADVISOR NO TEST CREATE SESSION NO TEST SELECT ANY DICTIONARY NO TEST UNLIMITED TABLESPACE NO SQL> SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE = 'TEST'; GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRA HIE ------------------------------ ------------------------------ ------------------------------ ------------------------------ ---------------------------------------- --- --- TEST SYS DBMS_WORKLOAD_REPOSITORY SYS EXECUTE NO NO （4）如果权限不足，重新创建用户，或给用户授权。命令参考 -- （CBD数据库可以使用如下SQL创建新账号，<username>需要以C##开头） create user <username> identified by <password>; grant EXECUTE on DBMS_WORKLOAD_REPOSITORY to <username> container=all; grant SELECT ANY DICTIONARY, ADVISOR, CREATE SESSION, ALTER SYSTEM to <username> container=all; --非CDB数据库可以使用如下SQL创建新账号: create user <username> identified by <password>; grant EXECUTE on DBMS_WORKLOAD_REPOSITORY to <username>; grant SELECT ANY DICTIONARY, ADVISOR, CREATE SESSION, ALTER SYSTEM to <username>; （5）重新点击进入【数据库接入管理】→【编辑】→【连通性测试】→【开始测试】，验证账号权限是否正确。 情况三：数据库类型为SQL Server数据库 （1）点击【数据库接入管理】→【编辑】，查看账号所需权限和创建指引。 （2）登录数据库 （3）查询用户权限，权限为：具备SELECT ALL USER SECURABLES，VIEW SERVER STATE，VIEW ANY DEFINITION，VIEW ANY DATABASE 等权限和db_datareader 角色 命令参考： SELECT pr.name AS principal_name, pr.type_desc AS principal_type, pe.permission_name, pe.state_desc AS permission_state FROM sys.server_permissions pe JOIN sys.server_principals pr ON pe.grantee_principal_id = pr.principal_id WHERE pr.name = 'test'; SELECT pr.name AS role_name, mp.name AS member_name FROM sys.database_role_members rm JOIN sys.database_principals pr ON rm.role_principal_id = pr.principal_id JOIN sys.database_principals mp ON rm.member_principal_id = mp.principal_id WHERE mp.name = 'test';   （4）给用户授予权限或重新创建账户，命令参考 DECLARE @login NVARCHAR(MAX) DECLARE @password NVARCHAR(MAX) DECLARE @sql NVARCHAR(MAX) -- 设置登录名和密码 SET @login = '<login>' SET @password = '<Password>' SET @sql = N' IF NOT EXISTS(SELECT 1 FROM sys.sql_logins WHERE name = '''+ @login + N''') CREATE LOGIN ' + QUOTENAME(@login) + N' WITH PASSWORD=N'''+ @password +''', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=ON; GRANT VIEW SERVER STATE TO ' + QUOTENAME(@login) + N'; GRANT VIEW ANY DEFINITION TO ' + QUOTENAME(@login) + N'; GRANT VIEW ANY DATABASE TO ' + QUOTENAME(@login) + N'; EXEC master.dbo.sp_MSforeachdb '' USE [?]; IF NOT EXISTS(SELECT 1 FROM sys.database_principals WHERE name ='''''+ @login + N''''') CREATE USER ' + QUOTENAME(@login) + N' FOR LOGIN ' + QUOTENAME(@login) + N'; EXEC sp_addrolemember N''''db_datareader'''', ' + QUOTENAME(@login) + N' '' ' EXEC sp_executesql @sql （5）重新点击进入【数据库接入管理】→【编辑】→【连通性测试】→【开始测试】，验证账号权限是否正确。 接入的数据库账号权限不满足平台要求 方案一：按照指引创建接入数据库的账号并授予对应的权限 （1）页面查看所需权限和命令示例                                

无法连接数据库，报错信息为：ERROR 1040 (08004): Too many connections      MySQL数据库连接数增长过快 MySQL数据库连接数使用率接近上限 尝试连接数据库 # mysql -uroot -p Enter password: ERROR 1040 (HY000): Too many connections 报错表示当前连接数已满 查看my.cnf 配置文件，默认情况下为 /etc/my.cnf # cat /etc/my.cnf |grep max_connections max_connections=151 查看my.cnf读取顺序 mysql --help --verbose |grep my.cnf order of preference, my.cnf, $MYSQL_TCP_PORT, /etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf max_connections 参数值设置过小（默认值只有151） 系统并发高 存在大量的 sleep 连接 存在锁阻塞，导致连接风暴 存在大量慢查询导致资源耗尽，最终形成了连接风暴 临时解决方案（注意：危险操作，请谨慎处理！！！） 使用拥有SUPPER权限的用户尝试登录数据库，并修改max_connections # mysql -uroot -p mysql> set global max_connections=5000; 若给普通用户赋予了“SUPPER”权限，这一步可能会失败。 若第一步失败，进行第二步：使用GDB临时修改 gdb -p `pidof mysqld` -ex 'set max_connections=5000' -batch 修改成功之后需要立即登录数据库，排查原因。 前面两个方法都不管用时：修改my.cnf文件，并重启数据库 max_connections=50000 # systemctl restart mysqld 若当前业务不允许重启，可以尝试主从切换。 彻底解决方案（注意：危险操作，请谨慎处理！！！） 修改my.cnf，并重启数据库 编辑my.cnf文件 max_connections=50000 重启数据库 检查当前业务是否正常，检查缓存是否失效（雪崩，穿透），限流没有生效等 检查程序代码，将使用完的连接进行close；使用连接池进行数据库连接，并设置最大连接数。 检查线程状态，监控是否存在大量的Lock和Wait字样 mysql> pager grep -E "lock|wait" PAGER set to 'grep -E "lock|wait"' mysql> show processlist; | 90517 | root | localhost | sbtest1 | Query | 38 | Waiting for global read lock | drop table sbtest1 | 5 rows in set (0.00 sec) 根据业务情况，kill 对应的线程。 kill <ID> ; 检查是否存在大量的慢SQL，其中timediff为事务执行时间 select *,timediff(now(),trx_started) timediff from innodb_trx\G 需要协调开发人员对语句进行分析并优化。                                    

数据库接入管理异常，平台持续5分钟未接收到客户端消息，已无法采集监控数据。   （1）登录信服云–数据库智能诊断–数据库接入管理，找到对应产生问题的数据库 （2）点击编辑，进入接入管理页面，进行连通性测试，查看原因 云端代理中的Agent上报数据异常，可能原因有：Agent异常的标准为5分钟没有心跳，异常原因可能为：1、云主机未开机，请开机后等待状态更新。2、性能优化工具异常，该异常原因仅出现在未安装成功时，如已安装成功请查看其他原因——（1）工具未安装，请安装后等待状态更新。（2）工具异常，请通过SSH查看HCI的系统日志（/sf/log/today/sfvt_vtpdaemon.log），若存在“通知虚拟机执行插件失败”日志，请重装性能优化工具后，重新安装Agent。（3）工具运行不稳定，Windows云主机请联系技术支持处理，Linux云主机请在云主机控制台查看日志（/var/log/sangfor/mod5_inst0.log），若存在“download plugin failed or timeout”日志，请重装性能优化工具后，重新安装Agent。3、标记文件残留，该异常原因仅出现在未安装成功时，如已安装成功请查看其他原因。Windows云主机请联系技术支持处理，Linux云主机请在云主机控制台查看日志（/var/log/sangfor/mod5_inst0.log），若存在“install aops plugin job is already running”日志，请手动删除标记文件（/tmp/installing_aops_plugin_flag）后，重新安装Agent。4、Agent进程（aops-spa,aops-spm）停止，Windows云主机请通过任务管理器查看进程，Linux云主机请输入ps aux |grep aops-spm查看进程，若进程不存在，请联系技术支持处理。5、云主机与云端代理通信异常，可用云主机ping云端代理IP地址，解决对应的网络问题。从而导致数据库智能诊断的接入管理异常，无法正常管理 登录云端代理检查Agent状态，按照提示的可能原因登录云主机排查并修复Agent，等待Agent正常（1）登录云端代理平台检查，排查Agent情况 （2）查看对应云主机的Agent状态和修复Agent （3）如果上述修复Agent步骤无法修复，需要登录该云主机查看具体状态并修复 （4）发现该云主机被关机，需要重新开机，保证Agent正常运行 （5）再次检查数据库接入管理，其他情况类似需要保证Agent正常后才能正常接入数据库智能诊断                      

数据库接入管理异常，平台无法使用提供的账号密码连接数据库，请检查账号密码是否正确、权限是否符合要求   （1）登录信服云–数据库智能诊断–数据库接入管理，找到对应产生问题的数据库     （2）点击编辑，进入接入管理页面，进行连通性测试，查看原因     （3）从报错来看，是填写的账号密码不对，尝试修改为正确的账号密码，重新进行连通性测试     接入管理填写的账号密码不对，或者数据库后台修改了账号密码，发生变更后导致接入管理检测到配置的账号密码错误 在数据库接入管理中填写正确的账号密码，进行连通性测试并确定保存                  

数据库智能诊断服务自动诊断出当前数据库实例存在性能或可优化问题   （1）登录云端智能大脑--数据库智能诊断–性能诊断     （2）选择对应数据库实例查看所有诊断事件，点击分析建议，按照处置建议处理     使用数据库智能诊断的分析建议进行处置        

数据库接入管理异常，平台无法连接访问当前接入的数据库.     （1）点击【数据库接入管理】→ 【编辑】→ 【连通性测试】→ 【开始测试】，查看原因。 （2）登录数据库后台，检查数据库异常原因 情况一：数据库类型为MySQL数据库 （1）检查常见操作系统资源 磁盘：df -h 内存：free -h CPU：top （2）查看mysqld进程是否正常 ps -ef|grep mysqld （3）检查端口是否能正常访问 telnet <ip> <port> netstat -tunlp |grep <port>   情况二：数据库类型为Oracle数据库 （1）检查常见操作系统资源 磁盘：df -h 内存：free -h CPU：top （2）检查监听器进程是否启动 ps -ef|grep tns （3）检查pmon进程是否正常 ps -ef|grep pmon （4）检查数据库状态 su - oracle sqlplus / as sysdba SQL> select status from v$instance; SQL> select open_mode from v$database; （5）检查集群组件是否正常 <grid_home>/crsctl status res -t （6）查看 Oracle 警告日志文件，寻找与问题相关的错误或警告信息。警告日志通常位于 Oracle 的 alert_<SID>.log 文件中   情况三：数据库类型为SQL Server数据库 （1）使用资源监视器检查磁盘，内存，CPU等占用使用正常 磁盘： 资源监视器： （2）使用计算机管理检查SQL Server相关服务是否正常 数据库相关进程异常，导致无法连接   方案一： （1）检查数据库相关进程，并确定故障原因                            

Oracle表空间剩余量不足 Oracle数据库表空间不足 常规查询系统表空间状况，最后一个列CARE列，低于20天预计使用天数，则需考虑是否增加 SQL> set lines 200 col group_number for 99 col state for a15 col name for a20 col total_gb for 999999.99 col free_gb for 999999.99 col free_percent for 99.99 col care for a5 set linesize 131 set pagesize 200 set termout off set trimspool on set serveroutput on set lines 200 pages 300 col tablespace_name for a30 ---check_tbs select u.*,round(p.avg_use_per_day_mb,1) avg_used_per_day_mb,round((max_size_mb-size_used_mb)/p.avg_use_per_day_mb) tbs_exhaust_days, case when u.MAX_FREE_RATE<7 and round((max_size_mb-size_used_mb)/p.avg_use_per_day_mb)<30 then '*' else null end care from (select a.tablespace_name,b.size_used_mb,a.data_size_mb, round(100-b.size_used_mb/a.data_size_mb*100) free_rate, a.max_size_mb, a.max_size_mb - b.size_used_mb free_mb, round(100-b.size_used_mb/a.max_size_mb*100) max_free_rate from (select tablespace_name,round(sum(bytes/1024/1024)) data_size_mb,round(sum(case when maxbytes>bytes then maxbytes else bytes end)/1024/1024) max_size_mb from dba_data_files group by tablespace_name) a, (select tablespace_name,round(sum(bytes/1024/1024)) size_used_mb from dba_segments group by tablespace_name) b where a.tablespace_name=b.tablespace_name order by 6 desc,4 desc) u, (select name,avg(use_per_day_mb)+0.0001 avg_use_per_day_mb from (select x.name,x.rdate,(x.used_blocks-lag(x.used_blocks) over (partition by name order by rdate))*y.block_size/1024/1024 use_per_day_mb from (select to_char(to_date(rtime,'mm/dd/yyyy hh24:mi:ss'),'yyyy-mm-dd') rdate ,name,max(tablespace_usedsize) used_blocks from dba_hist_tbspc_space_usage a,v$tablespace b where a.tablespace_id=b.ts# group by to_char(to_date(rtime,'mm/dd/yyyy hh24:mi:ss'),'yyyy-mm-dd'),name order by name ) x,dba_tablespaces y where x.name=y.tablespace_name ) where use_per_day_mb is not null group by name) p where u.TABLESPACE_NAME=p.name and u.TABLESPACE_NAME not like '%UNDO%' and u.TABLESPACE_NAME not like '%TEMP%' order by 4,7; 2.RAC查询ASM磁盘组空间剩余情况，单机查询文件系统空间剩余情况 RAC: SQL> select group_number,name,total_mb/1024 TOTAL_GB,free_mb/1024 FREE_GB,free_mb/total_mb*100 free_percent,state,TYPE,(case when free_mb/total_mb*100 < 15 then '*' else '' end ) care from v$ASM_DISKGROUP; 单机： SQL> !df -h #一定要注意ASM/文件系统空间充足才可以做表空间扩容动作   3.查询表空间的类型,块大小，数据文件是否自动扩展，是否BIGFILE SQL> col tablespace_name for a20 col contents for a10 col block_size for 9999 col bigfile for a10 col AUTOEXTENSIBLE for a10 col file_name for a65 col file_Id for 99999 select a.tablespace_name,contents,block_size,bigfile,file_id,file_name,AUTOEXTENSIBLE from ( select TABLESPACE_NAME,BLOCK_SIZE,CONTENTS,BIGFILE from dba_tablespaces) a, (select file_id,file_name,tablespace_name,AUTOEXTENSIBLE from dba_data_files) b where a.tablespace_name=b.tablespace_name and a.tablespace_name=upper('&TABLESPACE_NAME');   4.查询正在使用数据文件数量 SQL> select count(*) from v$datafile;   5.查询当前数据库中可管理的数据文件最大数量 SQL> show parameter db_files #要注意数据库中可管理的数据文件最大数量要大于正在使用数据文件数量   以上排查步骤能定位是否有表空间剩余量不足，以及是否有足够的空间和文件数量去扩容相应表空间。 1.常规查询系统表空间状况，最后一个列CARE列，低于20天预计使用天数，则需考虑是否增加 SQL> set lines 200 col group_number for 99 col state for a15 col name for a20 col total_gb for 999999.99 col free_gb for 999999.99 col free_percent for 99.99 col care for a5 set linesize 131 set pagesize 200 set termout off set trimspool on set serveroutput on set lines 200 pages 300 col tablespace_name for a30 ---check_tbs select u.*,round(p.avg_use_per_day_mb,1) avg_used_per_day_mb,round((max_size_mb-size_used_mb)/p.avg_use_per_day_mb) tbs_exhaust_days, case when u.MAX_FREE_RATE<7 and round((max_size_mb-size_used_mb)/p.avg_use_per_day_mb)<30 then '*' else null end care from (select a.tablespace_name,b.size_used_mb,a.data_size_mb, round(100-b.size_used_mb/a.data_size_mb*100) free_rate, a.max_size_mb, a.max_size_mb - b.size_used_mb free_mb, round(100-b.size_used_mb/a.max_size_mb*100) max_free_rate from (select tablespace_name,round(sum(bytes/1024/1024)) data_size_mb,round(sum(case when maxbytes>bytes then maxbytes else bytes end)/1024/1024) max_size_mb from dba_data_files group by tablespace_name) a, (select tablespace_name,round(sum(bytes/1024/1024)) size_used_mb from dba_segments group by tablespace_name) b where a.tablespace_name=b.tablespace_name order by 6 desc,4 desc) u, (select name,avg(use_per_day_mb)+0.0001 avg_use_per_day_mb from (select x.name,x.rdate,(x.used_blocks-lag(x.used_blocks) over (partition by name order by rdate))*y.block_size/1024/1024 use_per_day_mb from (select to_char(to_date(rtime,'mm/dd/yyyy hh24:mi:ss'),'yyyy-mm-dd') rdate ,name,max(tablespace_usedsize) used_blocks from dba_hist_tbspc_space_usage a,v$tablespace b where a.tablespace_id=b.ts# group by to_char(to_date(rtime,'mm/dd/yyyy hh24:mi:ss'),'yyyy-mm-dd'),name order by name ) x,dba_tablespaces y where x.name=y.tablespace_name ) where use_per_day_mb is not null group by name) p where u.TABLESPACE_NAME=p.name and u.TABLESPACE_NAME not like '%UNDO%' and u.TABLESPACE_NAME not like '%TEMP%' order by 4,7;     1.表空间未开启自动扩展 2.表空间下数据文件写满 首先要确认表空间种类。如果是SYSTEM表空间SYSAUX表空间，我们需要排查分析表空间数据占比大的原因。如果是其他类型的表空间，那么我们只需要做表空间扩容动作即可。 从排查步骤3#中得到需要扩容表空间是否是BIGFILE类型表空间,再用以下命令扩容 --Bigfile类型表空间 SQL> alter database datafile '&file_name' autoextend on next 3G maxsize 3336g; --small类型表空间 SQL> Alter tablespace '&TABLESPACE_NAME' add datafile '+DATA' size 30G; SYSTEM表空间： 首先查询SYSTEM表空间对象 SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, BYTES / 1024 / 1024 /1024 AS SIZE_GB FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'SYSTEM' ORDER BY SIZE_MB DESC; 由上图可知，system表空间占比最多的是OPTSTAT_SNAPSHOT$表，其中I_OPTSTAT_SNAPSHOT$是其索引。 从 12R2 开始，在收集统计信息时，会执行以下 INSERT 语句。表的 DML 监控信息从 sys.mon_mods_all$ 复制到 OPTSTAT_SNAPSHOT$，然后 OPTSTAT_SNAPSHOT$ 会增长并占用 SYSTEM 表空间：  insert /* KSXM:TAKE_SNPSHOT */ into sys.optstat_snapshot$ (obj#, inserts, updates, deletes, timestamp, flags) (select m.obj#, m.inserts, m.updates, m.deletes, systimestamp, dbms_stats_advisor.compute_volatile_flag( m.obj#, m.flags, :flags, m.inserts, m.updates, m.deletes, s.inserts, s.updates, s.deletes, null, nvl(to_number(p.valchar), :global_stale_pcnt), s.gather) flags from sys.mon_mods_all$ m, (select si.obj#, max(si.inserts) inserts, max(si.updates) updates, max(si.deletes) deletes, decode(bitand(max(si.flags), :gather_flag), 0, 'NO_GATHER', 'GATHER') gather, max(si.timestamp) timestamp from sys.optstat_snapshot$ si, (select obj#, max(timestamp) ts from sys.optstat_snapshot$ group by obj#) sm where si.obj# = sm.obj# and si.timestamp = sm.ts group by si.obj#) s, sys.optstat_user_prefs$ p where m.obj# = s.obj#(+) and m.obj# = p.obj#(+) and pname(+) = 'STALE_PERCENT' and m.obj# = :objn)   1.查看当前表保留了多久数据 SQL> select min(TIMESTAMP),max(TIMESTAMP) from OPTSTAT_SNAPSHOT$; MIN(TIMESTAMP) MAX(TIMESTAMP) --------------------------------------------------------------------------- 18-08-13 21:46:26.998000 +09:00 18-09-13 21:05:14.794000 +09:00 <<<<< The historical data is just stored for one month, due to Statistics Purge Job.   2.清除10天前的统计信息历史记录（注意：危险操作，请谨慎处理！！！） SQL> begin 2 dbms_stats.purge_stats(sysdate-10); 3 end; 4 /   3.再次查询该表数据量大小 SQL> select SEGMENT_NAME, segment_type, bytes/(1024*1024*1024) SIZE_GB from 2 dba_segments where owner = 'SYS' and segment_name like '%OPTSTAT_SNAPSHOT%'; SEGMENT_NAME SEGMENT_TYPE SIZE_GB ------------------------------------------------------------ OPTSTAT_SNAPSHOT$ TABLE 6.109375 I_OPTSTAT_SNAPSHOT$ INDEX 3.6484375 发现数据量并未减少，因为尽管数据有保留周期，但高水位线可能持续增长，所以我们需要降低该表高水位（注意：危险操作，请谨慎处理！！！） 挪表（降低高水位）： SQL> alter table OPTSTAT_SNAPSHOT$ move tablespace system; SQL> alter index I_OPTSTAT_SNAPSHOT$ rebuild;   SYSAUX表空间： 查看SYSAUX表空间内详细占存储空间的比重信息  SQL> col Item for a30 col Schema for a20 col MoveProcedure for a60 set lines 200 SELECT occupant_name"Item", round(space_usage_kbytes/1024/1024,3)"Space Used (GB)", schema_name "Schema", move_procedure "MoveProcedure" FROM v$sysaux_occupants ORDER BY 2 Desc; Item Space Used (GB) Schema MoveProcedure ------------------------------ --------------- -------------------- ---------------------------------------- SM/OPTSTAT 31.362 SYS SM/AWR 11.027 SYS SM/ADVISOR .133 SYS XDB .127 XDB XDB.DBMS_XDB.MOVEXDB_TABLESPACE EM .092 SYSMAN emd_maintenance.move_em_tblspc SDO .061 MDSYS MDSYS.MOVE_SDO XSOQHIST .032 SYS DBMS_XSOQ.OlapiMoveProc AO .031 SYS DBMS_AW.MOVE_AWMETA SM/OTHER .021 SYS LOGMNR .013 SYSTEM SYS.DBMS_LOGMNR_D.SET_TABLESPACE TEXT .004 CTXSYS DRI_MOVE_CTXSYS 清理 SM/AWR 占用的空间（注意：危险操作，请谨慎处理！！！）查找到那些占用sysaux表空间的基表，按照大小进行排序  set line 300 col SEGMENT_NAME for a50 col PARTITION_NAME for a40 select * from (select segment_name,PARTITION_NAME,segment_type,bytes/1024/1024 from dba_segments where tablespace_name='SYSAUX' order by 4 desc) where rownum<=15; SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE BYTES/1024/1024 -------------------------------------- ------------------------------ ------------------ --------------- WRH$_ACTIVE_SESSION_HISTORY WRH$_ACTIVE_1595423027_0 TABLE PARTITION 16916 WRH$_EVENT_HISTOGRAM_PK WRH$_EVENT__1595423027_0 INDEX PARTITION 3419 WRH$_ACTIVE_SESSION_HISTORY_PK WRH$_ACTIVE_1595423027_0 INDEX PARTITION 2560 WRH$_EVENT_HISTOGRAM WRH$_EVENT__1595423027_0 TABLE PARTITION 2304 WRH$_LATCH_MISSES_SUMMARY_PK WRH$_LATCH__1595423027_0 INDEX PARTITION 1344 WRH$_LATCH WRH$_LATCH_1595423027_0 TABLE PARTITION 1280 WRH$_LATCH_MISSES_SUMMARY WRH$_LATCH__1595423027_0 TABLE PARTITION 1280 WRH$_SYSSTAT_PK WRH$_SYSSTA_1595423027_0 INDEX PARTITION 1002 WRH$_SQLSTAT WRH$_SQLSTA_1595423027_0 TABLE PARTITION 824 WRH$_LATCH_PK WRH$_LATCH_1595423027_0 INDEX PARTITION 824 WRH$_SYSSTAT WRH$_SYSSTA_1595423027_0 TABLE PARTITION 792 15 rows selected. --检查当前快照的保留设置 col SNAP_INTERVAL for a40 col RETENTION for a30 select * from dba_hist_wr_control; DBID SNAP_INTERVAL RETENTION TOPNSQL ---------- ---------------------------------------- ------------------------------ ---------- 1595423027 +00000 01:00:00.0 +00030 00:00:00.0 DEFAULT --检查最小和最大快照ID，根据快照ID来定们边界值，以便找到要删除和保留内容 SQL> select min(snap_id),max(snap_id) from dba_hist_snapshot; MIN(SNAP_ID) MAX(SNAP_ID) ------------ ------------ 19194 19928 SQL> select min(SNAP_ID),max(SNAP_ID) from WRH$_ACTIVE_SESSION_HISTORY; MIN(SNAP_ID) MAX(SNAP_ID) ------------ ------------ 1 19930 SQL> select count(*) from sys.wrh$_active_session_history a where not exists (select 1 from sys.wrm$_snapshot b where a.snap_id = b.snap_id and a.dbid = b.dbid and a.instance_number = b.instance_number); COUNT(*) ---------- 19194   WRH$_ACTIVE_SESSION_HISTORY清理：（注意：危险操作，请谨慎处理！！！）方法一：修改_swrf_test_action参数为72（参考mos文档ID 387914.1） SQL> alter session set "_swrf_test_action" = 72; 方法二：查表基本的组织结构发现WRH$表中都有snap_id字段，备份WRH$_ACTIVE_SESSION_HISTORY表保留数据到WRH$_ACTIVE_SESSION_HISTORY_B表。 SQL> CREATE TABLE WRH$_ACTIVE_SESSION_HISTORY_B AS SELECT * FROM WRH$_ACTIVE_SESSION_HISTORY WHERE SNAP_ID>19194 ; or: CREATE TABLE WRH$_ACTIVE_SESSION_HISTORY_B tablespace ITPUX AS SELECT * FROM WRH$_ACTIVE_SESSION_HISTORY WHERE SNAP_ID>19194 ; --验证WRH$_ACTIVE_SESSION_HISTORY_B表存储及包含数据 SQL> SELECT COUNT(*) FROM WRH$_ACTIVE_SESSION_HISTORY_B; --禁用AWR exec dbms_workload_repository.modify_snapshot_settings(interval => 0); --清除源表WRH$_ACTIVE_SESSION_HISTORY数据 SQL> TRUNCATE TABLE sys.WRH$_ACTIVE_SESSION_HISTORY; 查看索引的状态 select INDEX_NAME,PARTITION_NAME,STATUS from DBA_IND_PARTITIONS where INDEX_OWNER='SYS' AND INDEX_NAME='WRH$_ACTIVE_SESSION_HISTORY_PK'; EXEC dbms_stats.gather_table_stats(ownname => 'SYS',tabname => 'WRH$_ACTIVE_SESSION_HISTORY',cascade => TRUE); select * from dba_indexes where degree not in ('1','0','DEFAULT'); 两种方法清理了AWR数据之后，你会发现SYSAUX表空间的空间并没有被回收，使用率还和之前一样，这是因为清理AWR操作是通过DELETE操作实现的，表的水位线并没有下降导致的。 --将备份数据恢复至源表 SQL> INSERT INTO WRH$_ACTIVE_SESSION_HISTORY SELECT * FROM WRH$_ACTIVE_SESSION_HISTORY_B; SQL> COMMIT; --验证基表数据 SQL> SELECT COUNT(*) FROM WRH$_ACTIVE_SESSION_HISTORY; --重建索引 select 'alter index sys.WRH$_ACTIVE_SESSION_HISTORY_PK rebuild partition '||PARTITION_NAME||';' sql from DBA_IND_PARTITIONS where INDEX_OWNER='SYS' AND INDEX_NAME='WRH$_ACTIVE_SESSION_HISTORY_PK'; SQL> alter index sys.WRH$_ACTIVE_SESSION_HISTORY_PK rebuild partition WRH$_ACTIVE_SES_MXDB_MXSN; SQL> alter index sys.WRH$_ACTIVE_SESSION_HISTORY_PK rebuild partition WRH$_ACTIVE_1145986741_323; --启动AWR exec dbms_workload_repository.modify_snapshot_settings(interval => 60); --删除备份临时表 SQL> drop table WRH$_ACTIVE_SESSION_HISTORY_B purge; --按照上面的操作方式，将其余占空间的WRH$_开头的表继续清除数据， WRH$_EVENT_HISTOGRAM WRH$_LATCH WRH$_LATCH_MISSES_SUMMARY WRH$_SQLSTAT --检查确认 ------切换日志 alter system switch logfile; --查看日志信息是否正常(两个节点都检查，或执行oraalert命令检查) tail -100f $ORACLE_BASE/diag/rdbms/$ORACLE_UNQNAME/$ORACLE_SID/trace/alert_$ORACLE_SID.log   清理 SM/OPTSTAT 占用的空间：（注意：危险操作，请谨慎处理！！！） 查看统计信息保留时间  SQL> select dbms_stats.get_stats_history_retention from dual; GET_STATS_HISTORY_RETENTION --------------------------- 31 SQL> select DBMS_STATS.GET_STATS_HISTORY_AVAILABILITY from dual; GET_STATS_HISTORY_AVAILABILITY --------------------------------------------------------------------------- 20-AUG-24 06.25.02.223127000 PM +08:00 SYSAUX表空间OPTSTAT的段信息  SQL> select SEGMENT_NAME,SEGMENT_TYPE,ROUND(BYTES/1024/1024/1024,2) GB from DBA_SEGMENTS where TABLESPACE_NAME='SYSAUX' and owner='SYS' AND SEGMENT_NAME LIKE '%OPTSTAT%' ORDER BY 3 DESC; SEGMENT_NAME SEGMENT_TYPE GB --------------------------------------- ------------------ ---------- WRI$_OPTSTAT_HISTHEAD_HISTORY TABLE 6.96 I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST INDEX 5.87 I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST INDEX 4.84 WRI$_OPTSTAT_HISTGRM_HISTORY TABLE 4.13 I_WRI$_OPTSTAT_HH_ST INDEX 4.05 I_WRI$_OPTSTAT_H_ST INDEX 3.28 I_WRI$_OPTSTAT_TAB_OBJ#_ST INDEX .07 WRI$_OPTSTAT_TAB_HISTORY TABLE .04 WRI$_OPTSTAT_OPR TABLE .04 I_WRI$_OPTSTAT_TAB_ST INDEX .04 I_WRI$_OPTSTAT_OPR_STIME INDEX .02 52 rows selected. 查询表中有多长时间的数据  SQL> select min(savtime),max(savtime) from sys.WRI$_OPTSTAT_HISTGRM_HISTORY; MIN(SAVTIME) MAX(SAVTIME) ---------------------------------------------- -------------------------------------- 03-JUL-23 06.40.26.614403 PM +08:00 20-AUG-24 06.14.05.792829 PM +08:00 SQL> select min(savtime),max(savtime) from sys.WRI$_OPTSTAT_HISTHEAD_HISTORY; MIN(SAVTIME) MAX(SAVTIME) ---------------------------------------- --------------------------------------- 13-NOV-23 08.12.23.235042 PM +08:00 20-AUG-24 06.14.05.792829 PM +08:00 SQL> select sysdate-to_date('2023-07-03','yyyy-mm-dd') from dual; SYSDATE-TO_DATE('2023-07-03','YYYY-MM-DD') ------------------------------------------ 50.8110764 SQL> select sysdate-to_date('2023-11-13','yyyy-mm-dd') from dual; SYSDATE-TO_DATE('2023-11-13','YYYY-MM-DD') ------------------------------------------ 282.811215 删除31天之前的历史数据，一次循环建议1星期，删除1天提交一次，减少大事务的出现（注意：危险操作，请谨慎处理！！！） SQL> begin for i in reverse 275..282 loop dbms_stats.purge_stats(sysdate-i); commit; end loop; end; / ----删除直到保留15天的数据 SQL> begin for i in reverse 15..25 loop dbms_stats.purge_stats(sysdate-i); commit; end loop; end; / --注意：如果数据量过大，会产生大量的redo、undo影响数据库的性能，需要在系统负载小的时间执行。 SQL> select min(savtime),max(savtime) from sys.WRI$_OPTSTAT_HISTHEAD_HISTORY; 调整统计信息保留时间为15天  SQL> exec dbms_stats.alter_stats_history_retention(15); SQL> select dbms_stats.get_stats_history_retention from dual; 因为purge_stats用delete的方式删除数据，虽然数据没了，但是HWM还没降下来，查看OPTSTAT使用哪些表，然后降低其高水位，执行move操作（注意：危险操作，请谨慎处理！！！） SQL> select SEGMENT_NAME,SEGMENT_TYPE,ROUND(BYTES/1024/1024/1024,2) GB from DBA_SEGMENTS where TABLESPACE_NAME='SYSAUX' and owner='SYS' AND SEGMENT_NAME LIKE '%OPTSTAT%' ORDER BY 3 DESC; SEGMENT_NAME SEGMENT_TYPE GB ------------------------------ ------------------ ---------- WRI$_OPTSTAT_HISTHEAD_HISTORY TABLE 6.84 I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST INDEX 5.19 I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST INDEX 4.77 I_WRI$_OPTSTAT_HH_ST INDEX 4.05 WRI$_OPTSTAT_HISTGRM_HISTORY TABLE 3.69 I_WRI$_OPTSTAT_H_ST INDEX 2.91 I_WRI$_OPTSTAT_TAB_OBJ#_ST INDEX .07 WRI$_OPTSTAT_TAB_HISTORY TABLE .04 WRI$_OPTSTAT_OPR TABLE .04 I_WRI$_OPTSTAT_TAB_ST INDEX .04 I_WRI$_OPTSTAT_OPR_STIME INDEX .02 52 rows selected. 查看SYSAUX表空间OPTSTAT的行数  SQL> select a.table_name,a.num_rows from dba_tables a where a.tablespace_name='SYSAUX' and a.table_name like '%OPTSTAT%' order by 2 desc; TABLE_NAME NUM_ROWS ------------------------------ ---------- WRI$_OPTSTAT_HISTHEAD_HISTORY 3262946 WRI$_OPTSTAT_HISTGRM_HISTORY 1713230 WRI$_OPTSTAT_TAB_HISTORY 519181 WRI$_OPTSTAT_OPR 325024 WRI$_OPTSTAT_IND_HISTORY 28089 WRI$_OPTSTAT_SYNOPSIS_HEAD$ 0 WRI$_OPTSTAT_SYNOPSIS_PARTGRP 0 WRI$_OPTSTAT_AUX_HISTORY 0 8 rows selected. 查出相关表的索引，因为move表，索引会失效，需要重建索引（注意：危险操作，请谨慎处理！！！） SQL> set line 300 col TABLE_OWNER for a20 col TABLE_NAME for a30 select i.table_owner,i.table_name,i.index_name,i.status from dba_indexes i,dba_objects s where i.table_name=s.object_name and s.object_type='TABLE' and s.object_name like 'WRI$_OPTSTAT%' order by 2,3; TABLE_OWNER TABLE_NAME INDEX_NAME STATUS ------------------------------ ------------------------------ ------------------------------ -------- SYS WRI$_OPTSTAT_AUX_HISTORY I_WRI$_OPTSTAT_AUX_ST VALID SYS WRI$_OPTSTAT_HISTGRM_HISTORY I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST VALID SYS WRI$_OPTSTAT_HISTGRM_HISTORY I_WRI$_OPTSTAT_H_ST VALID SYS WRI$_OPTSTAT_HISTHEAD_HISTORY I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST VALID SYS WRI$_OPTSTAT_HISTHEAD_HISTORY I_WRI$_OPTSTAT_HH_ST VALID SYS WRI$_OPTSTAT_HISTHEAD_HISTORY SYS_IL0000000494C00016$$ VALID SYS WRI$_OPTSTAT_IND_HISTORY I_WRI$_OPTSTAT_IND_OBJ#_ST VALID SYS WRI$_OPTSTAT_IND_HISTORY I_WRI$_OPTSTAT_IND_ST VALID SYS WRI$_OPTSTAT_OPR I_WRI$_OPTSTAT_OPR_STIME VALID SYS WRI$_OPTSTAT_SYNOPSIS_HEAD$ I_WRI$_OPTSTAT_SYNOPHEAD VALID SYS WRI$_OPTSTAT_SYNOPSIS_HEAD$ SYS_C003484 VALID 15 rows selected. 创建一个临时用的表空间，执行表的move操作（注意：危险操作，请谨慎处理！！！） SQL> CREATE TABLESPACE sysaux_t DATAFILE '+DATA' SIZE 5G AUTOEXTEND ON NEXT 50M MAXSIZE 32764M; SQL> alter table sys.WRI$_OPTSTAT_HISTGRM_HISTORY move tablespace sysaux_t; SQL> alter table sys.WRI$_OPTSTAT_HISTGRM_HISTORY move tablespace sysaux; SQL> alter table sys.WRI$_OPTSTAT_HISTHEAD_HISTORY move tablespace sysaux_t; SQL> alter table sys.WRI$_OPTSTAT_HISTHEAD_HISTORY move tablespace sysaux; SQL> alter index sys.I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST rebuild online; SQL> alter index sys.I_WRI$_OPTSTAT_H_ST rebuild online; SQL> alter index sys.I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST rebuild online; SQL> alter index sys.I_WRI$_OPTSTAT_HH_ST rebuild online;   首先要确认表空间种类。如果是SYSTEM表空间SYSAUX表空间，我们需要排查分析表空间数据占比大的原因。如果是其他类型的表空间，那么我们只需要做表空间扩容动作即可。 从排查步骤3#中得到需要扩容表空间是否是BIGFILE类型表空间,再用以下命令扩容 --Bigfile类型表空间 SQL> alter database datafile '&file_name' autoextend on next 3G maxsize 3336g; --small类型表空间 SQL> Alter tablespace '&TABLESPACE_NAME' add datafile '+DATA' size 30G;