行パーティションが新しい現行日付またはタイムスタンプ値に調整されるテーブルの名前。
例: パーティション式が複数のCURRENT_DATE関数に基づく場合のテーブルの行パーティションの変更
テーブルでは直近の2つの四半期がそれぞれ個別に行パーティション化されており、その他のすべてのデータが別の行パーティションにあるとします。以下の例では各四半期の開始時にCURRENT_DATEを調整します。テーブルは2009年1月1日に作成されているとします。従って、CURRENT_DATEは作成時に2009年1月1日に解決されます。
CREATE SET TABLE sales, NO FALLBACK ( storeID INTEGER, amount DECIMAL(10,2), sale_date DATE FORMAT 'YYYY/MM/DD' NOT NULL) PRIMARY INDEX (storeID) PARTITION BY CASE_N(sale_date>=CURRENT_DATE/*latest quarter data*/, sale_date<CURRENT_DATE AND sale_date>=CURRENT_DATE-INTERVAL '3' MONTH, NO CASE);
テーブルには、解決された2009年1月1日のCURRENT_DATEを持つ次の行が含まれています。
sales | |||
---|---|---|---|
StoreID | Amount | Sale_Date | PARTITION |
1 | 1000.00 | 2009-01-31 | 1 |
1 | 2000.00 | 2009-01-01 | 1 |
1 | 3500.00 | 2009-01-15 | 1 |
1 | 500.00 | 2008-09-15 | 2 |
1 | 2000.00 | 2008-12-15 | 2 |
1 | 5000.00 | 2009-04-01 | 3 |
2009年4月1日に次のリクエストを実行するとします。
ALTER TABLE sales TO CURRENT;
解決されたCURRENT_DATEは2009年4月1日に変わり、テーブルの行は次のように調整されます。
sales | |||
---|---|---|---|
StoreID | Amount | Sale_Date | PARTITION |
1 | 1000.00 | 2009-01-31 | 2 |
1 | 2000.00 | 2009-01-01 | 2 |
1 | 3500.00 | 2009-01-15 | 2 |
1 | 500.00 | 2008-09-15 | 3 |
1 | 2000.00 | 2008-12-15 | 3 |
1 | 5000.00 | 2009-04-01 | 3 |
2009年1月1日に次のCREATE TABLEリクエストを実行したとします。
CREATE SET TABLE customer, NO FALLBACK ( cust_name CHARACTER(10), cust_no INTEGER, policy_expiration_date DATE FORMAT 'YYYY/MM/DD' NOT NULL) PRIMARY INDEX (cust_no) PARTITION BY CASE_N(policy_expiration_date>=CURRENT_DATE, policy_expiration_date<CURRENT_DATE AND policy_expiration_date>=CURRENT_DATE- INTERVAL '3' MONTH);
テーブルの行には、2009年1月1日に解決されたCURRENT_DATEが入り、次のようになります。
customer | |||
---|---|---|---|
cust_name | cust_no | policy_expiration_date | PARTITION |
Li | 1 | 2009-01-31 | 1 |
Khan | 2 | 2009-01-01 | 1 |
Reddy | 3 | 2009-01-15 | 1 |
Smith | 5 | 2008-12-15 | 2 |
2009年4月1日に次のALTER TABLE TO CURRENTリクエストを実行します。
ALTER TABLE customer TO CURRENT;
次の行は、改定されたCURRENT_DATE値に基づくどの行パーティションにも移動できないため、システムは要求元にエラー メッセージを返します。
customer | |||
---|---|---|---|
cust_name | cust_no | policy_expiration_date | PARTITION |
Smith | 5 | 2008-12-15 | 2 |
このエラーを回避するには、代わりに2009年4月1日に次のALTER TABLE TO CURRENTリクエストを実行します。
ALTER TABLE customer TO CURRENT WITH DELETE;
このALTER TABLE TO CURRENTリクエストの結果として、Teradata Databaseはもう関係がなくなったために次の行をテーブルから削除します。
customer | |||
---|---|---|---|
cust_name | cust_no | policy_expiration_date | PARTITION |
Smith | 5 | 2008-12-15 | 2 |
テーブルの行には、2009年4月1日に解決されたCURRENT_DATEが入り、次のようになります。
customer | |||
---|---|---|---|
cust_name | cust_no | policy_expiration_date | PARTITION |
Li | 1 | 2009-01-31 | 2 |
Khan | 2 | 2009-01-01 | 2 |
Reddy | 3 | 2009-01-15 | 2 |
例: CREATE TABLEリクエストでのCURRENT_DATE関数の最適化されない使用法
この例は、CASE_N条件内でCURRENT_DATE関数を指定しますが、この方法ではALTER TABLE TO CURRENTリクエストを使用した調整を、全パーティションよりも少ないパーティション数をスキャンするように最適化できません。この結果、customerに対してALTER TABLE TO CURRENTリクエストが実行されるたびに、Teradata Databaseは新たに解決される日付の行パーティションを調整するために、フル テーブル スキャンを実行する必要があります。
CREATE SET TABLE customer, NO FALLBACK ( cust_name CHARACTER(10), cust_no INTEGER, policy_expiration_date DATE FORMAT 'YYYY/MM/DD') PRIMARY INDEX(cust_no) PARTITION BY CASE_N(policy_expiration_date=CURRENT_DATE, NO CASE);
例: CREATE TABLEリクエストでのCURRENT_DATE関数の最適化されない使用法
この例でも、CASE_N条件の引数としてCURRENT_DATE関数を指定しますが、この方法ではALTER TABLE TO CURRENTリクエストを使用した調整を、customerの全行パーティションよりも少ないパーティション数をスキャンするように最適化できません。
このリクエストは2つの異なるパーティション列にCURRENT_DATE関数を指定しますが、Teradata Databaseはどのような場合にある行パーティションのすべての行が影響を受けないのかを判別できません。これは、新たに解決される日付の影響を判別するために使用できるpolicy_expiration_date列とbirth_date列との間の既知の関係がないためです。この結果、customerに対してALTER TABLE TO CURRENTリクエストが実行されるたびに、Teradata Databaseは新たに解決される日付の行パーティションを調整するために、フル テーブル スキャンを実行する必要があります。
CREATE SET TABLE customer, NO FALLBACK ( cust_name CHARACTER(10), cust_no INTEGER, birth_date DATE, policy_expiration_date DATE FORMAT 'YYYY/MM/DD') PRIMARY INDEX (cust_no) PARTITION BY CASE_N(policy_expiration_date >= CURRENT_DATE, policy_expiration_date >= CURRENT_DATE, birth_date < CURRENT_DATE - INTERVAL '20' YEAR, NO CASE);