

# RDS for PostgreSQL の NOTICE メッセージの説明
<a name="Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE"></a>

 `postgres_get_av_diag()` 関数は、次の NOTICE メッセージを提供します。

**経過時間がまだモニタリングしきい値に達していない場合**  
ブロック要因を識別するための `postgres_get_av_diag()` のモニタリングしきい値は、デフォルトで 5 億トランザクションです。`postgres_get_av_diag()` で次の NOTICE が生成された場合は、トランザクション経過時間がまだこのしきい値に達していないことを示します。  

```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```

**トランザクション ID の経過時間が最も古いデータベースに接続していない**  
`postgres_get_av_diag()` 関数は、トランザクション ID の経過時間が最も古いデータベースに接続したときに、最も正確な出力を提供します。`postgres_get_av_diag()` によって報告されたトランザクション ID の経過時間が最も古いデータベースが、「my\$1database」とは異なる場合があります。正しいデータベースに接続していない場合、次の NOTICE が生成されます。  

```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
トランザクション経過時間が最も古いデータベースに接続することは、次の理由で重要です。  
+ **一時テーブルのブロック要因の識別:** 一時テーブルのメタデータは各データベースに固有のため、通常、一時テーブルは作成されたデータベースにあります。ただし、一時テーブルが上位のブロック要因となり、最も古いトランザクションを持つデータベースに存在する状況では、誤解が生じる可能性があります。適切なデータベースに接続することで、一時テーブルのブロック要因を正確に識別できます。
+ **遅いバキュームの診断:** インデックスメタデータとテーブル数の情報はデータベース固有であり、バキュームが遅い問題の診断に必要です。

**トランザクションの経過時間が最も古いデータベースが、rdsadmin または template0 データベースにある**  
場合によっては、`rdsadmin` または `template0` データベースが、トランザクション ID の経過時間が最も古いデータベースとして識別される場合があります。このような場合、`postgres_get_av_diag()` で次の NOTICE が発行されます。  

```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
リストされたブロック要因がこれら 2 つのデータベースのいずれからも発生していないことを確認します。ブロック要因が `rdsadmin` または `template0` のいずれかに存在すると報告された場合は、サポートに問い合わせてください。ユーザーはこれらのデータベースにはアクセスできず、サポートが必要です。  
`rdsadmin` と `template0` データベースのいずれかに上位のブロック要因が含まれている可能性はほとんどありません。

**積極的なバキュームがすでに実行されている場合**  
`postgres_get_av_diag()` 関数は、積極的なバキューム処理が実行されているときに報告を行うように設計されていますが、この出力はバキュームが少なくとも 1 分間アクティブになった後にのみトリガーされます。この意図的な遅延によって、誤検出の可能性が低くなります。待機することで、有効で重要なバキュームのみが報告され、バキュームアクティビティのより正確で信頼性の高いモニタリングが可能になります。  
`postgres_get_av_diag()` 関数は、進行中の 1 つ以上の積極的なバキュームを検出すると、次の NOTICE を生成します。  

```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
NOTICE に示されているように、バキュームのパフォーマンスを引き続きモニタリングします。積極的なバキュームの詳細については、「[(循環を防ぐための) 積極的なバキューム処理が実行されている](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)」を参照してください。

**自動バキュームがオフの場合**  
データベースインスタンスで自動バキュームが無効になっている場合、`postgres_get_av_diag()` 関数は次の NOTICE を生成します。  

```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
自動バキュームは、RDS for PostgreSQL DB インスタンスの重要な機能であり、スムーズなデータベース操作を実現します。古い行バージョンを自動的に削除し、ストレージ領域を再利用して、テーブルの肥大化を防止することで、テーブルとインデックスの効率が維持され、パフォーマンスが最適化されます。さらに、Amazon RDS インスタンスのトランザクションを停止する可能性のある、トランザクション ID の循環も防止します。自動バキュームを無効にすると、データベースのパフォーマンスと安定性が長期的に低下する可能性があるため、常に有効にしておくことをお勧めします。詳細については、「[Understanding autovacuum in RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)」を参照してください。  
自動バキュームをオフにしても、積極的なバキュームは停止しません。積極的なバキュームは、テーブルが `autovacuum_freeze_max_age` しきい値に達すると実行されます。

**残っているトランザクションの数が非常に少ない**  
`postgres_get_av_diag()` 関数は、循環バキュームが差し迫った場合に次の NOTICE を生成します。この NOTICE は、Amazon RDS インスタンスが新しいトランザクションを拒否するまであと 1 億トランザクションに差し迫った場合に発行されます。  

```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
データベースのダウンタイムを回避するために、直ちにアクションが必要です。バキューム操作を注意深くモニタリングし、トランザクションの失敗を防ぐために、影響を受けるデータベースで `VACUUM FREEZE` を手動で開始することを検討する必要があります。