テーブル名がファイル名に含まれる1テーブル=1ファイルのファイルから partition 句だけを抽出したコマンドをメモ。
find . -iname '*table1*' -exec grep -A 10 -i 'partition' '{}' \;|perl -pe 's/^.*\.sql(:|-)//g'
テーブル名がファイル名に含まれる1テーブル=1ファイルのファイルから partition 句だけを抽出したコマンドをメモ。
find . -iname '*table1*' -exec grep -A 10 -i 'partition' '{}' \;|perl -pe 's/^.*\.sql(:|-)//g'
alter table schema1.test1 alter column col1 encode raw, alter column col2 encode raw, alter column col3 encode raw;
(Aurora) PostgreSQL の Transaction ID(XID) は AUTO VACUUM で autovacuum_freeze_max_age (デフォルトは2億)に達すると自動的に回収される。
以下は実際の CloudWatch メトリクスの MaximumUsedTransactionIDs のグラフの推移。
CloudWatch アラームで監視する場合は 3 億くらいにしておくとちょうどえぇかと思う。
autovacuumの強制実行
パフォーマンスチューニング9つの技 ~「基盤」について~|PostgreSQLインサイド : 富士通
データベース内で一番古いトランザクションIDと現在のトランザクションIDとの差(ageと言います)が2億個(autovacuum_freeze_max_ageパラメーターのデフォルト値)を超えるとautovacuumが強制的に実行され、想定外にデータベースの負荷が高くなることがあります。なお、利用できる残りのトランザクションIDの数が少なくなると、新たなトランザクションIDの割り振りが抑止され、インスタンスがエラーで操作できなくなることもあります。
autovacuum_freeze_max_age (integer)
Specifies the maximum age (in transactions) that a table's pg_class.relfrozenxid field can attain before a VACUUM operation is forced to prevent transaction ID wraparound within the table. Note that the system will launch autovacuum processes to prevent wraparound even when autovacuum is otherwise disabled.Vacuum also allows removal of old files from the pg_xact subdirectory, which is why the default is a relatively low 200 million transactions. This parameter can only be set at server start, but the setting can be reduced for individual tables by changing table storage parameters. For more information see Section 24.1.5.
PostgreSQL: Documentation: 12: 19.10. Automatic Vacuuming
Amazon Aurora の CloudWach メトリクス VolumeReadIOPs/VolumeWriteIOPs は5分間の合計、IOPS(秒間IO回数)は300秒(5分)で割って算出する必要がある。
Amazon Aurora の Amazon CloudWatch メトリクス - Amazon Aurora
- メトリクス:VolumeReadIOPs
- コンソール名:ボリューム読み取りの IOPS (カウント)
- Applies to:Aurora MySQL および Aurora PostgreSQL
- 単位:5 分あたりのカウント
- 説明:
- 5 分以内の、クラスターボリュームからの課金読み取り I/O オペレーションの回数。
- 課金読み取りオペレーションはクラスターボリュームレベルで計算され、Aurora DB クラスター内のすべてのインスタンスから集計された後、5 分おきに報告されます。この値は、5 分間にわたる読み取りオペレーションメトリクスの値を受け取ることによって計算されます。課金読み取りオペレーションメトリクスの値を受け取って 300 秒で割ることで、1 秒あたりの課金読み取りオペレーションの回数を決定できます。例えば、課金読み取りオペレーションが 13,686 を返す場合、1 秒あたりの課金読み取りオペレーションは 45 (13,686 / 300 = 45.62) です。
- バッファキャッシュにないデータベースのページをリクエストするクエリの課金読み取りオペレーションが発生します。これはストレージからロードする必要があります。課金読み取りオペレーションはストレージからクエリの結果が読み取られるのと同様に急増することがありますが、その後バッファキャッシュにロードされます。
- ヒント Aurora MySQL クラスターがパラレルクエリを使用している場合、VolumeReadIOPS 値が増加することがあります。パラレルクエリでは、バッファプールは使用されません。したがって、クエリは高速ですが、この最適化された処理により、読み取り操作とそれに関連する料金が増加する可能性があります。
Redshift のシステムビュー svv_table_info の情報を取得してもらったら、変なところで改行されてたので、補正したメモ。
% perl -nle 'print length($_)' svv_table_info.txt 271 95 271 95 271 95 ...
% perl -pe 's/\n//g' svv_table_info.txt >svv_table_info_nobr.txt
% fold -b366 svv_table_info_nobr.txt > svv_table_info_br.txt