この構成の続きです。
・構成
https://qiita.com/Cache-Hit/items/5f7f8788b4d97d4b553d
タイムトラベルについて
Snowflake特有の機能、タイムトラベルがほかのクラウドと比べてだいぶ異質であり便利なので紹介と検証結果を記載します。
機能紹介
タイムトラベルの特徴です。
①対象期間の設定
デフォルトでは1日に設定されており、
Enterprise Edition以上であれば最大90日に設定されています。
また、0にも設定できます。
一時的テーブルと仮テーブルは0または1日にしかできません。
設定はアカウント単位、データベース単位、スキーマ単位、テーブル単位で設定可能。
各設定可能な部分に個別の設定をすると、後述する復元時に問題が発生する場合があるので注意です。
②保存について
保存期間を日単位で設定できますが、
1日が1回のポイントではなく、24時間秒単位でとられているので、のちに記載する復元などでも便利です。
③参照
保存期間の中であれば、過去のデータを参照できます。
例えば、このクエリを流した前後、であればクエリIDを検索し指定して前後、
タイムスタンプを指定しその前後、など。
今のデータベースを複製などせず、
過去のデータと今のデータを比較も可能。
④復元
復元はクローンとして作成します。
例としてテーブルを設定する場合、テーブルを複製して、その後元のテーブルと中身を入れ替えることも可能です。
⑤料金
公式では明示的に料金は計算が難しいですが、
データとして変動したデータ分などですね。
①対象期間の設定
今の設定の確認
★Snowsightから確認
DBの設定を確認
SELECT DATABASE_NAME, RETENTION_TIME
FROM SNOWFLAKE.INFORMATION_SCHEMA.DATABASES
WHERE DATABASE_NAME = 'SNOWTESTDB';
2日に設定を変更
ALTER DATABASE SNOWTESTDB SET DATA_RETENTION_TIME_IN_DAYS = 2;
変更内容を確認
SELECT DATABASE_NAME, RETENTION_TIME
FROM SNOWFLAKE.INFORMATION_SCHEMA.DATABASES
WHERE DATABASE_NAME = 'SNOWTESTDB';
③参照
一度データを変更して過去のデータを参照してみます。
現状のテーブルを確認
SELECT * FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE LIMIT 100;
データ追加
INSERT INTO SNOWTESTDB.TEST_SCHEMA.TEST_TABLE (ID, NAME)
VALUES
(104, 'Fukuoka'),
(105, 'Sapporo'),
(106, 'Yokohama');
再度確認
SELECT * FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE LIMIT 100;
最後にINSERT文を流した履歴からクエリIDを検索します。
SELECT query_id FROM
TABLE(information_schema.query_history_by_session(result_limit=>50))
WHERE query_text LIKE 'INSERT%' ORDER BY start_time LIMIT 1;
このクエリIDを指定してその直前のデータを確認します。
SELECT * FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE
BEFORE (STATEMENT => '01c7c81e-0304-f946-0005-7192000d0e56');
変更前であることを確認。
クエリIDを指定して前後で比較
SELECT *
FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE AS A_NOW
WHERE NOT EXISTS(
SELECT 1
FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE AT(STATEMENT => '01c7c81e-0304-f946-0005-7192000d0e56') AS A_OLD
WHERE A_NOW.ID = A_OLD.ID
)
差分が正しいことを確認。
このクエリの情報を取得
SELECT *
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE QUERY_ID = '01c7c81e-0304-f946-0005-7192000d0e56';
クエリが終わった時間を確認
SELECT END_TIME
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE QUERY_ID = '01c7c81e-0304-f946-0005-7192000d0e56';
タイムスタンプを指定して、クエリを出す前と比較
SELECT *
FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE AS A_NOW
WHERE NOT EXISTS(
SELECT 1
FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE AT(TIMESTAMP => '2026-10-16 20:10'::TIMESTAMP_LTZ) AS A_OLD
WHERE A_NOW.ID = A_OLD.ID
)
クエリIDを指定して、そのクエリの前の状態をクローンとして、新規テーブルを【名前】_BKとして作成
CREATE TABLE SNOWTESTDB.TEST_SCHEMA.TEST_TABLE_BK
CLONE SNOWTESTDB.TEST_SCHEMA.TEST_TABLE
BEFORE (STATEMENT => '01c7c81e-0304-f946-0005-7192000d0e56');
作成されていることを確認
SELECT *
FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE_BK
ORDER BY ID;
前のデータであることを確認
対象をswapコマンドを利用して、
今のテーブルの中身を、クローンで作成した【名前】_BKと入れ替える。
ALTER TABLE SNOWTESTDB.TEST_SCHEMA.TEST_TABLE
SWAP WITH SNOWTESTDB.TEST_SCHEMA.TEST_TABLE_BK;
入れ替え後、クローンしたテーブルのデータが正しくなっていることを確認。
SELECT *
FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE
ORDER BY ID;
入れ替え後の【名前】_BKの方が、古いデータになっている事を確認
SELECT *
FROM SNOWTESTDB.TEST_SCHEMA.TEST_TABLE_BK
ORDER BY ID;
UNDROPコマンド
タイムトラベル期間中であれば、UNDROPコマンドにて、
DB、スキーマ、テーブルのそれぞれを瞬時に復元ができます。
試しにテーブルをDROPします。
DROP TABLE SNOWTESTDB.TEST_SCHEMA.TEST_TABLE;
無い事を確認をします。
SHOW TABLES LIKE 'TEST_TABLE'
IN SCHEMA SNOWTESTDB.TEST_SCHEMA;
UNDROPコマンドで復活させます。
UNDROP TABLE SNOWTESTDB.TEST_SCHEMA.TEST_TABLE;
確認
SHOW TABLES LIKE 'TEST_TABLE'
IN SCHEMA SNOWTESTDB.TEST_SCHEMA;
