嗨Marek，

请检查一下此参数吗？

2518441-PI系统的表空间PSAPSR3DB快速增长

xiadapter.inbound.persistDuration.default默认值86400000（1天）
xiadapter.outbound.persistDuration.default默认值86400000（1天）
messaging.log.RetainTime默认值7天

此外，您可以检查此URL以获取SAP表

SXMSCLUP-Cluster-压缩消息有效负载属性（53GB）

https://wiki.scn.sap.com/wiki/display/XI/PI+database+size+is+growing+large+SXMSCLUP%2C+SXMSCLUR

1791627-与Reorg作业相关的PI ABAP DB表
2167673-PI表SXMSCLUP的高速增长

您可以每天两次查询数据库中使用的空间，并使用一些查询并进入dbacockpit，以查找TOP 10中最大的表/索引。

致谢

很少有建议/问题可以使您的设置更好地了解：

-您可以量化'变得越来越大 '？ 100 MB/天？ 10 GB/天？

-您已经发布了 sp_spaceused 的一组输出； 连续几天的数字是什么样的？ 上升更快的是什么...数据或索引？

-您提到查看过索引大小...您是否看到任何表明这是索引空间使用问题的信息？ （与数据，blob或日志相对）

-您提到的"交易dbacockpit"是否显示索引ID为255的索引的空间使用情况？ （我想知道是否由于过多的文本/图像/blob数据值而使空间正在增加……而该空间在索引id = 255下占）

-是其上的日志 自己的设备还是与数据设备混在一起？

-事务日志是否存在空间问题？ （例如，由于长时间运行，日志可能会增长。打开txn吗？）

-该ASE实例是SAP应用程序的运行时数据库吗？ （Diego提到了一个' SAP表BC_MSG_LOG '，因此很好奇这实际上是否是前端上的SAP应用程序）

我决定更改"保留时间 时间段"，用于无错误的异步和同步消息。 从我所看到的删除作业将删除超过160k消息，这应该给我超过10GB的数据库空间。 这项工作是每天安排的，因此我们应该可以使用数据库空间。

我会将Diego邮件标记为解决方案。 它帮助我了解问题出在哪里。

干杯

好消息Marek！

Hello Marek，

此查询的托盘：

前10名 按已使用的已分配空间计算数据库中最大的表：

选择
前10个名称， used_pa​​ges（db_id（），id）
/(1024.0/（@@ maxpagesize/1024.0/1024.0））作为" Used GB"
来自
sysobjects
按
used_pa​​ges（db_id（），id）desc
go

排序

SAP表BC_MSG_LOG可能位于前五位。

通常问题不在ASE端，而是在PI内部，以及消息保留的定义。

检查此SAP注释：
2518441-PI系统的表空间PSAPSR3DB快速增长
2403587-即使已禁用自定义存档作业，默认删除作业也不起作用
2542867-PI适配器 引擎后台作业没有可用的日志
2771052-用于记录消息的保留期的PI全局参数未生效
2538365-如何在PI-PO系统上启用消息压缩
872388-存档和删除中的故障排除 PI

最好的问候

你好迭戈

感谢您的留言。

这是您的查询结果：

使用的GB --------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------

SXMSCLUP 53.90261840820312500000000000000000000000000

J2EE_CONFIGENTRY 3.47409057617187500000000000000000000000000

重新加载3.18267822265625000000000000000000000000000

SXMSCLUR 2.67825317382812500000000000000000000000000

系统日志2.37727355957031250000000000000000000000000

REPOSRC 2.28224182128906250000000000000000000000000

D010TAB 1.94796752929687500000000000000000000000000

SMIMCONT1 1.68455505371093750000000000000000000000000

DOKTL 1.13900756835937500000000000000000000000000

BC_SLD_INST 0.76576232910156156000000000000000000000000000000

（受影响的10行）

这是RSXMB_SHOW_REORG_STATUS报告的结果：

表容器：SXMSPMAST概述========

在以下

中，保留期以及消息和适配器状态被忽略

数据库中的消息数：641.203

客户端中的邮件数：641.203

客户端中仍要重组的消息数：641.204

保留期限================

类型状态操作配置开始时间（CET）

异步无错误存档660天14.07.2018 10:07:44

异步无错误删除200天17.10.2019 10:07:44

同步错误删除200天17.10.2019 10:07:44

同步无错误删除200天17.10.2019 10:07:44

删除======以下消息和适配器状态被忽略

-异步。 消息不在保留期内（可以删除）：0

-异步。 保留期间的邮件（无法删除）：56.525

以下内容尊重消息和适配器的状态

-异步。 消息不在保留期内（可以删除）：0

在以下内容中，消息状态被忽略

-同步。 消息不在保留期内（可以删除）：0

-同步。 保留期间的邮件（无法删除）：585.034

以下内容尊重消息状态

-没有错误的同步消息将被删除：0-

要删除错误的同步消息：0

================================================ ===========

我已经检查了后台作业处理监视器。 "默认删除作业"。

有效，上次状态成功，

频率1天。

我仍然不知道出什么问题了，为什么我的数据库越来越大，但是我将研究Sap Note" 872388-对PI中的归档和删除进行故障排除"，以进一步了解PI中的后台作业 。

嗨，Marek，

我的Sybase数据库越来越大，我简直不明白为什么会这样

>>请检查是否为您担心的数据库启用了任何阈值。

关于，
Dilip Voora