A nightly COPY remains waiting because another session has not finished updating the same table.
Before safely resuming the load, identify the current transactions and the lock holder.
Which investigation should be performed first?
Use STV_LOCKS for current table locks and SVV_TRANSACTIONS for open transactions and contention, then choose a targeted recovery action.
Detailed explanation
Redshift system views identify the table, lock owner, process, and open transaction so the impact can be assessed before recovery.
Redshift system views identify the table, lock owner, process, and open transaction so the impact can be assessed before recovery.
CloudTrail records API activity, not the current Redshift transaction and table-lock state needed here.
CloudTrail records API activity, not the current Redshift transaction and table-lock state needed here.
This loses the cause and can interrupt unrelated work; observe and limit the recovery scope first.
This loses the cause and can interrupt unrelated work; observe and limit the recovery scope first.
S3 Lifecycle manages object retention and tiers; it does not resolve a lock held inside Redshift.
S3 Lifecycle manages object retention and tiers; it does not resolve a lock held inside Redshift.
Check official documentation
Compare the following points with the official documentation.
Amazon RedshiftのSTV_LOCKS、SVV_TRANSACTIONS、STL_TR_CONFLICTの公式説明を確認する。
Official references
What to confirm
ストレージライフサイクルやAPI監査と、データベース内部のロック競合の調査方法を区別できる。
Key points
- STV_LOCKS
- SVV_TRANSACTIONS
- Lock owner
- Short transaction
Notes
- Environment: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- Confirm the relevant DEA-C01 Skill and current AWS service documentation.
Foundation review
Observation first
Identify the blocker and impact before ending or retrying a session.
Transaction scope
Keep write transactions short so locks are released promptly.