

 Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。

# テーブルの復元
<a name="serverless-table-restore"></a>

 スナップショットまたは復旧ポイントから特定のテーブルを復元することもできます。この場合は、ソース スナップショットまたは復旧ポイント、データベース、スキーマ、テーブル、ターゲットデータベース、スキーマ、新しいテーブル名を指定します。この新しいテーブルは、既存のテーブルと同じ名前は使用できません。テーブルを復元して既存のテーブルを置き換える場合は、テーブルを復元する前に、まずテーブル名を変更するか削除する必要があります。

**注記**  
RA3 でプロビジョニングされたクラスターと Amazon Redshift Serverless ワークグループでは、バックアップ用ではないテーブルはサポートされていません。RA3 クラスターおよびサーバーレスワークグループでバックアップしないとマークされたテーブルは、スナップショットの作成中に常にバックアップされ、スナップショットから復元するときに復元される永続テーブルとして扱われます。ただし、バックアップ用ではないテーブルの選択的な復元はサポートされていません。

 ターゲットテーブルは、ソーステーブルの列の定義、テーブル属性、および外部キーを除く列の属性を使って作成されます。依存関係による競合を回避するため、ターゲットテーブルはソーステーブルから外部キーを継承しません。ソーステーブルで付与されたビューや許可などの依存関係は、ターゲットテーブルに適用されません。

ソーステーブルの所有者が存在するなら、そのユーザーは指定されたデータベースおよびスキーマの関係において所有者となるのに十分なアクセス許可がある場合にのみ、復元されたテーブルの所有者となります。それ以外の場合には、クラスターの起動時に作成した管理者ユーザーが、復元されたテーブルを所有します。

復元されたテーブルは、バックアップが作成された時の状態に戻されます。これには、Amazon Redshift の[直列化分離](https://docs.aws.amazon.com/redshift/latest/dg/c_serial_isolation.html)への準拠により定義されるトランザクションの可視性のルールが含まれます。つまり、バックアップ後に開始した実行中のトランザクションにデータがすぐに見えるようになるということです。

 Amazon Redshift Serverless コンソールを使用して、スナップショットからテーブルを復元できます。

データバックアップからのテーブルの復元には、次のとおりの制限があります。
+ 一度に復元できるのは 1 つのテーブルのみです。
+ ソーステーブルで付与されたビューや許可などの依存関係は、ターゲットテーブルに適用されません。
+ 復元中のテーブルに対して行レベルのセキュリティが有効になっている場合、Amazon Redshift Serverless は、行レベルのセキュリティがオンになっているテーブルを復元します。

Amazon Redshift Serverless コンソールを使用してテーブルを復元するには

1. Amazon Redshift Serverless コンソールで、**[Data backup]** (データのバックアップ) を選択します。

1. 復元するテーブルを含むスナップショットまたは復旧ポイントを選択します。

1. **[アクション]**、**[スナップショットからテーブルを復元する]** または **[Restore table from recovery point]** を選択します。

1. ソースのスナップショットまたは復旧ポイントとターゲットテーブルに関する情報を入力して、**[テーブルの復元]** をクリックします。