1

私は P6 管理者でも、(SQL Server) DBA でもありません。私はただの Winforms 開発者 (T-SQL を使用) であり、スケジューリング グループのためにちょっとした調査を行うことに同意しています。

彼らが実行しているバージョンは 8.2、デスクトップ (非 Citrix) だと思います。バックエンドは SQL Server です。バックエンドは 36 GB に成長し、毎晩のバックアップは定期的にドライブを限界までいっぱいにしています。

REFRDEL には 1 億 3,500 万のレコードがあり、2012 年のある時点までさかのぼります。UDFVALUE には 2,600 万のレコードがあります。

他のすべてのテーブルには、適切な数のレコードがあります。

いくつかのクリーンアップ指向のストアド プロシージャのどれを実行するか (もしあれば) を教えてくれる人、またはバックエンドを管理可能なサイズに縮小できるように適切なアドバイスを提供してくれる人はいますか? ベスト プラクティスに違反せず、非常に安全であると考えられるものをお願いします。

4

3 に答える 3

2

これに来るのは少し遅れましたが、次のことが役立つかもしれないと考えました。REFRDEL が大きなサイズに成長していることに気付き、いくつかの調査の結果、次のことがわかりました... DAMON

は次の手順を実行してクリーンアップを実行します。

  • BGPLOG_CLEANUP
  • REFRDEL_CLEANUP
  • REFRDEL バイパス
  • CLEANUP_PRMQUEUE
  • USESSION_CLEAR_LOGICAL_DELETES
  • CLEANUP_LOGICAL_DELETES
  • PRMAUDIT_CLEANUP
  • CLEANUP_USESSAUD
  • 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 週間に 1 回だけ実行されます...そしてクリーンアップ ジョブを実行すると、1 日分のデータしか削除されませんが、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 に答える
2

データベースのデータを見ると、「delete_session_id」という列名があります。-99 の値を持つものはありますか? もしそうなら、これには未解決の問題があります。そうでない場合は、次の手順に進み、クリーンアップ ジョブを再度実行します...

SQL Server (フル エディション) を使用している場合は、次の手順を実行して問題を解決します。

  1. SQL Server エージェント サービスがサーバー上で開始され、スタートアップの種類が自動であることを確認します。

    • このサービスのログは (デフォルトで) 次の場所にあります。
    • C:\Program Files\Microsoft SQL Server\\LOG\SQLAGENT.x
    • このログには、サービスがいつ停止/開始されたかに関する情報が含まれます

  2. SQL エージェントが開始されている場合は、SQL Query Analyzer (2000) または Microsoft SQL Server Management Studio を介して SA として次のコマンドを発行することにより、SQL Server データベースに存在するジョブを確認できます。

    • select * from msdb.dbo.sysjobs

  3. Primavera バックグラウンド プロセス (SYMON および DAMON) がリストされていない場合、または SQL エージェントが開始されていない場合は、Project Management データベースに対して SA ユーザーとして次のコマンドを実行することにより、これらのバックグラウンド プロセスを再初期化できます。

    • exec initialize_background_procs
    • exec system_monitor
    • exec data_monitor
于 2015-01-25T14:14:05.987 に答える
1

UDFVALUE が多数のレコードを保持するのは正常です。P6 の任意のオブジェクトに関連付けられた任意のユーザー定義フィールドの各値は、このテーブルのレコードとして表されます。

一方、REFRDEL は、健全なシステムでの通常の操作中に自動的にクリーンアップされる必要があります。P6 8.x では、data_monitor プロセスによってクリーンアップする必要があります。デフォルトでは、週に 1 回 (土曜日) 実行するように構成されています。

手動で実行できるはずですが、2012 年以降適切に実行されていない場合、完了するまでに長い時間がかかる可能性があることに注意してください。

36GB は依然として非常に大きなデータベースです。一部のクライアントにとって、アクティビティの総数、特に保存されるデータの種類によっては、その規模のデータベースが不合理ではない場合があります。たとえば、メモ帳は比較的多くのスペースを占めます。

ただし、あなたの場合、 data_monitor がしばらくの間正しく実行されていないことはすでにわかっているため、テーブルがソフト削除されたがまだパージされていないレコードでいっぱいである可能性が高くなります。次のようなクエリを実行すると、そのようなレコードを表示できます。

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

ビューはこれらの論理的に削除されたレコードを自動的に除外するため、ビューではなくタスク テーブルから選択する必要があることに注意してください。

そのようなレコードを手動で削除しないでください。これらは、data_monitor を実行した結果として、REFRDEL 内のレコードと共にクリーンアップされる必要があります。

于 2015-01-22T23:41:10.997 に答える