1

我不是 P6 管理员，也不是 (SQL Server) DBA。我只是一名 Winforms 开发人员（使用 T-SQL），同意为调度组做一些研究。

我相信他们正在运行的版本是 8.2，桌面（非 Citrix）。后端是 SQL Server。后端已增长到 36GB，夜间备份会定期将驱动器填充到极限。

REFRDEL 拥有 1.35 亿条记录，可以追溯到 2012 年的某个时间。UDFVALUE 拥有 2600 万条记录

所有其他表都有合理数量的记录。

有人可以告诉我们要运行几个面向清理的存储过程中的哪一个（如果有的话），或者提供一些明智的建议，以便我们可以将后端缩小到可管理的大小，好吗？一些不会违反最佳实践并且被认为非常安全的东西，请。

4

3 回答 3

2

当您查看数据库中的数据时，有一个列名“delete_session_id”。你看到任何值为-99的东西吗？如果是这样，那么在这方面有一个未解决的问题。如果没有，请继续执行以下操作以再次运行清理作业...

如果您使用的是 SQL Server（完整版），请执行以下步骤来解决问题：

  1. 验证 SQL Server 代理服务是否已在服务器上启动并且具有自动启动类型。

    • 可以在以下位置找到此服务的日志（默认情况下）：
    • C:\Program Files\Microsoft SQL Server\\LOG\SQLAGENT.x
    • 此日志包含有关服务何时停止/启动的信息

  2. 如果 SQL 代理已启动，则可以通过 SQL 查询分析器 (2000) 或 Microsoft SQL Server Management Studio 以 SA 身份发出以下命令，检查 SQL Server 数据库中存在哪些作业：

    • 从 msdb.dbo.sysjobs 中选择 *

  3. 如果未列出 Primavera 后台进程（SYMON 和 DAMON），或者未启动 SQL 代理，则可以通过以 SA 用户身份对 Project Management 数据库运行以下命令来重新初始化这些后台进程：

    • 执行 initialize_background_procs
    • 执行系统监视器
    • 执行数据监视器
于 2015-01-25T14:14:05.987 回答
2

有点晚了，但认为以下内容可能对某些人有用。我们注意到 REFRDEL 已经增长到一个很大的规模，经过一些调查发现了以下情况......

DAMON 运行以下程序来执行清理：

  • BGPLOG_CLEANUP
  • REFRDEL_CLEANUP
  • REFRDEL 旁路
  • CLEANUP_PRMQUEUE
  • USESSION_CLEAR_LOGICAL_DELETES
  • CLEANUP_LOGICAL_DELETES
  • PRMAUDIT_CLEANUP
  • CLEANUP_USESAUD
  • USER_DEFINED_BACKGROUND

DAMON 被配置为每周六下午 4 点左右运行，但我们注意到它一直在失败。这是由于从晚上 10 点开始的脱机备份过程。我们首先假设这会阻止 REFRDEL_CLEANUP 运行。
然而，在监视 REFRDEL 几周后，我们发现 REFRDEL_CLEANUP实际上正在运行并从表中删除数据。您可以通过在第 1 周运行以下查询来检查您的表，然后在第 2 周再次运行以验证是否删除了最旧的记录。

select min(delete_date), max(delete_date), count(*) from admuser.refrdel;


问题与 REFRDEL_CLEANUP 过程使用的默认参数有关。这些在此处进行了描述，但总而言之，该过程设置为保留最近 5 天的记录并仅删除 1 天的记录。这就是导致问题的原因......DAMON 每周只运行一次......当它运行清理作业时，它只删除 1 天的数据，但已经积累了一周的价值......因此数据量会变得更大和更大。
可以在 SETTINGS 表中覆盖默认参数。
以下是我为解决此问题而采取的步骤：
首先，清理桌子..

-- 1. create backup table
CREATE TABLE ADMUSER.REFRDEL_BACKUP TABLESPACE PMDB_DAT1 NOLOGGING AS
Select * from admuser.refrdel where delete_date >= (sysdate - 5);

-- CHECK DATA HAS BEEN COPIED


-- 2. disable indexes on REFRDEL
alter index NDX_REFRDEL_DELETE_DATE unusable;
alter index NDX_REFRDEL_TABLE_PK unusable;

-- 3. truncate REFRDEL table
truncate table admuser.refrdel;

-- 4. restore backed up data
ALTER TABLE ADMUSER.REFRDEL NOLOGGING;
insert /*# append */ into admuser.refrdel select * from admuser.refrdel_backup;
--verify number of rows copied
ALTER TABLE ADMUSER.REFRDEL LOGGING;

commit;

-- 5. rebuild indexes on REFRDEL
alter index NDX_REFRDEL_DELETE_DATE rebuild;
alter index NDX_REFRDEL_TABLE_PK rebuild;

-- 6. gather table stats
exec dbms_stats.gather_table_stats(ownname => 'ADMUSER', tabname => 'REFRDEL', cascade => TRUE);

-- 7. drop backup table
drop table admuser.refrdel_backup purge;

接下来，覆盖参数，以便我们尝试删除至少 10 天的数据。保留期将始终保留 5 天的数据。

exec settings_write_string(‘10',’database.cleanup.Refrdel’,’DaysToDelete’);   -- delete the oldest 10 days of data
exec settings_write_string(’15’,’database.cleanup.Refrdel’,’IntervalStep’);   -- commit after deleting every 15 minutes of data
exec settings_write_string(‘5d’,’database.cleanup.Refrdel’,’KeepInterval’);   -- only keep 5 most recent days of data

这最后一步仅与我的环境相关，除非您遇到类似问题，否则不适用于您。这是为了改变 DAMON 的开始时间，使其在我们的离线备份过程开始之前完成。所以在这种情况下，我将开始时间从下午 4 点更改为午夜。

BEGIN
  DBMS_SCHEDULER.SET_ATTRIBUTE (
   name         =>  'BGJOBUSER.DAMON',
   attribute    =>  'start_date',
   value        =>  TO_TIMESTAMP_TZ('2016/08/13 00:00:00.000000 +00:00','yyyy/mm/dd hh24:mi:ss.ff tzr'));
END;
/
于 2016-08-17T10:31:49.770 回答
1

UDFVALUE 保存大量记录是正常的。附加到 P6 中任何对象的任何用户定义字段的每个值都将表示为该表中的一条记录。

另一方面，REFRDEL 应该在健康系统的正常运行期间自动清理。在 P6 8.x 中，它们应该由 data_monitor 进程清理，该进程默认配置为每周运行一次（周六）。

您应该可以手动执行它，但请注意：如果自 2012 年以来未正确执行，可能需要很长时间才能完成。

36gb 仍然是一个非常非常大的数据库。对于某些客户而言，这种规模的数据库可能并非不合理，具体取决于活动的总数，尤其是存储的数据类型。例如，记事本占用的空间比较大。

但是，在您的情况下，由于您已经知道 data_monitor 有一段时间没有正确执行，因此表更有可能充满了已软删除但尚未清除的记录。您可以通过运行以下查询来查看此类记录：

select count(*) from task where delete_session_id is not null;

请注意，您必须从任务表中选择，而不是从视图中选择，因为视图会自动过滤掉这些软删除的记录。

您不应手动删除此类记录。由于运行 data_monitor，它们应该与 REFRDEL 中的记录一起被清理。

于 2015-01-22T23:41:10.997 回答