Snowflake Time Travel là một tính năng mạnh mẽ cho phép bạn truy cập dữ liệu lịch sử, tức là dữ liệu đã bị thay đổi hoặc xóa, tại bất kỳ thời điểm nào trong một khoảng thời gian xác định. Với Snowflake Time Travel, việc khôi phục các đối tượng bị xóa do vô tình hoặc cố ý trở nên dễ dàng hơn bao giờ hết, đồng thời hỗ trợ sao chép và sao lưu dữ liệu từ các thời điểm quan trọng trong quá khứ. Bạn đang tìm kiếm một nền tảng đăng ký trực tuyến dễ sử dụng và hỗ trợ khách hàng hiệu quả? Hãy truy cập ngay click2register.net để khám phá những giải pháp mà chúng tôi cung cấp. Tại đây, bạn sẽ tìm thấy các công cụ và thông tin cần thiết để quản lý các sự kiện, khóa học và dịch vụ trực tuyến một cách dễ dàng và hiệu quả.
1. Giới Thiệu Về Snowflake Time Travel
Sử dụng Time Travel, bạn có thể thực hiện các hành động sau trong một khoảng thời gian xác định:
- Truy vấn dữ liệu trong quá khứ đã được cập nhật hoặc xóa.
- Tạo bản sao của toàn bộ bảng, lược đồ và cơ sở dữ liệu tại hoặc trước các thời điểm cụ thể trong quá khứ.
- Khôi phục bảng, lược đồ, cơ sở dữ liệu và một số loại đối tượng khác đã bị xóa.
Lưu ý: Khi truy vấn dữ liệu lịch sử trong bảng hoặc chế độ xem không được hiện thực hóa, lược đồ bảng hoặc chế độ xem hiện tại sẽ được sử dụng.
Sau khi khoảng thời gian xác định trôi qua, dữ liệu sẽ được chuyển vào Snowflake Fail-safe và không thể thực hiện các hành động này nữa.
Lưu ý: Một truy vấn Time Travel chạy dài sẽ trì hoãn việc di chuyển bất kỳ dữ liệu và đối tượng nào (bảng, lược đồ và cơ sở dữ liệu) trong tài khoản vào Fail-safe, cho đến khi truy vấn hoàn tất.
1.1. Các Mở Rộng SQL Time Travel
Để hỗ trợ Time Travel, các phần mở rộng SQL sau đây đã được triển khai:
| Phần Mở Rộng SQL | Mô Tả |
|---|---|
AT | BEFORE |
Thêm các tùy chọn này vào câu lệnh SELECT để truy vấn dữ liệu khi nó xuất hiện trong quá khứ. |
AT | BEFORE |
Thêm các tùy chọn này vào câu lệnh CREATE ... CLONE để sao chép một bảng, lược đồ hoặc cơ sở dữ liệu tại một thời điểm trong quá khứ. |
UNDROP |
Khôi phục bảng, lược đồ hoặc cơ sở dữ liệu đã bị xóa. |
Tham số đối tượng DATA_RETENTION_TIME_IN_DAYS |
Chỉ định số ngày để giữ lại dữ liệu lịch sử, cho phép thực hiện các thao tác Time Travel (SELECT, CREATE … CLONE, UNDROP) trên dữ liệu. Tham số này có thể được đặt ở cấp độ tài khoản, cơ sở dữ liệu, lược đồ và bảng. Để biết thêm thông tin, hãy xem DATA_RETENTION_TIME_IN_DAYS. |
1.2. Thời Gian Lưu Giữ Dữ Liệu
Một thành phần quan trọng của Snowflake Time Travel là thời gian lưu giữ dữ liệu.
Khi dữ liệu trong bảng được sửa đổi, bao gồm xóa dữ liệu hoặc xóa một đối tượng chứa dữ liệu, Snowflake sẽ giữ lại trạng thái của dữ liệu trước khi cập nhật. Thời gian lưu giữ dữ liệu chỉ định số ngày mà dữ liệu lịch sử này được giữ lại và do đó, các thao tác Time Travel (SELECT, CREATE … CLONE, UNDROP) có thể được thực hiện trên dữ liệu.
Thời gian lưu giữ tiêu chuẩn là 1 ngày (24 giờ) và được tự động kích hoạt cho tất cả các tài khoản Snowflake:
-
Đối với Snowflake Standard Edition, thời gian lưu giữ có thể được đặt thành 0 (hoặc bỏ đặt lại thành mặc định là 1 ngày) ở cấp độ tài khoản và đối tượng (tức là cơ sở dữ liệu, lược đồ và bảng).
-
Đối với Snowflake Enterprise Edition (và cao hơn):
- Đối với cơ sở dữ liệu, lược đồ và bảng tạm thời, thời gian lưu giữ có thể được đặt thành 0 (hoặc bỏ đặt lại thành mặc định là 1 ngày). Điều này cũng đúng với các bảng tạm thời.
- Đối với cơ sở dữ liệu, lược đồ và bảng vĩnh viễn, thời gian lưu giữ có thể được đặt thành bất kỳ giá trị nào từ 0 đến 90 ngày.
Lưu ý: Thời gian lưu giữ 0 ngày cho một đối tượng sẽ tắt Time Travel cho đối tượng đó.
Khi thời gian lưu giữ kết thúc cho một đối tượng, dữ liệu lịch sử sẽ được chuyển vào Snowflake Fail-safe:
- Dữ liệu lịch sử không còn khả dụng để truy vấn.
- Các đối tượng trong quá khứ không còn có thể được sao chép.
- Các đối tượng trong quá khứ đã bị xóa không còn có thể được khôi phục.
Để chỉ định thời gian lưu giữ dữ liệu cho Time Travel:
- Tham số đối tượng DATA_RETENTION_TIME_IN_DAYS có thể được sử dụng bởi người dùng có vai trò ACCOUNTADMIN để đặt thời gian lưu giữ mặc định cho tài khoản của bạn.
- Tham số tương tự có thể được sử dụng để ghi đè rõ ràng giá trị mặc định khi tạo cơ sở dữ liệu, lược đồ và bảng riêng lẻ.
- Thời gian lưu giữ dữ liệu cho cơ sở dữ liệu, lược đồ hoặc bảng có thể được thay đổi bất kỳ lúc nào.
- Tham số tài khoản MIN_DATA_RETENTION_TIME_IN_DAYS có thể được đặt bởi người dùng có vai trò ACCOUNTADMIN để đặt thời gian lưu giữ tối thiểu cho tài khoản. Tham số này không thay đổi hoặc thay thế giá trị tham số DATA_RETENTION_TIME_IN_DAYS. Tuy nhiên, nó có thể thay đổi thời gian lưu giữ dữ liệu hiệu quả. Khi tham số này được đặt ở cấp độ tài khoản, thời gian lưu giữ dữ liệu tối thiểu hiệu quả cho một đối tượng được xác định bởi MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS).
1.3. Các Hạn Chế
Khi sử dụng Time Travel, các loại đối tượng sau không được sao chép:
- Bảng bên ngoài
- Các giai đoạn nội bộ (Snowflake)
- Các bảng lai có thể được sao chép cho cơ sở dữ liệu nhưng không phải cho lược đồ.
- Các tác vụ người dùng trong cơ sở dữ liệu hoặc lược đồ không được sao chép khi sử dụng CREATE SCHEMA … TIMESTAMP. Trong ví dụ sau, các tác vụ trong lược đồ nguồn (S1) không được sao chép vào lược đồ có dấu thời gian (S2) nhưng được sao chép vào lược đồ không có dấu thời gian (S3).
CREATE SCHEMA S1;
USE SCHEMA S1;
CREATE TASK T1 AS SELECT 1;
CREATE SCHEMA S2 CLONE S1 AT(TIMESTAMP => '2025-04-01 12:00:00'); -- T1 không được sao chép vào S2
CREATE SCHEMA S3 CLONE S1; -- T1 được sao chép vào S32. Kích Hoạt Và Hủy Kích Hoạt Time Travel
Không cần tác vụ nào để kích hoạt Time Travel. Nó được tự động kích hoạt với thời gian lưu giữ tiêu chuẩn là 1 ngày.
Tuy nhiên, bạn có thể muốn nâng cấp lên Snowflake Enterprise Edition để cho phép định cấu hình thời gian lưu giữ dữ liệu dài hơn lên đến 90 ngày cho cơ sở dữ liệu, lược đồ và bảng. Lưu ý rằng việc mở rộng thời gian lưu giữ dữ liệu yêu cầu thêm dung lượng lưu trữ, điều này sẽ được phản ánh trong phí lưu trữ hàng tháng của bạn. Để biết thêm thông tin về phí lưu trữ, hãy xem Chi phí lưu trữ cho Time Travel và Fail-safe.
Time Travel không thể bị hủy kích hoạt cho một tài khoản. Người dùng có vai trò ACCOUNTADMIN có thể đặt DATA_RETENTION_TIME_IN_DAYS thành 0 ở cấp độ tài khoản, điều này có nghĩa là tất cả các cơ sở dữ liệu (và do đó tất cả các lược đồ và bảng) được tạo trong tài khoản không có thời gian lưu giữ theo mặc định; tuy nhiên, giá trị mặc định này có thể bị ghi đè bất kỳ lúc nào cho bất kỳ cơ sở dữ liệu, lược đồ hoặc bảng nào.
Người dùng có vai trò ACCOUNTADMIN cũng có thể đặt MIN_DATA_RETENTION_TIME_IN_DAYS ở cấp độ tài khoản. Cài đặt tham số này áp dụng thời gian lưu giữ dữ liệu tối thiểu cho cơ sở dữ liệu, lược đồ và bảng. Đặt MIN_DATA_RETENTION_TIME_IN_DAYS không thay đổi hoặc thay thế giá trị tham số DATA_RETENTION_TIME_IN_DAYS. Tuy nhiên, nó có thể thay đổi thời gian lưu giữ dữ liệu hiệu quả cho các đối tượng. Khi MIN_DATA_RETENTION_TIME_IN_DAYS được đặt ở cấp độ tài khoản, thời gian lưu giữ dữ liệu cho một đối tượng được xác định bởi MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS).
Time Travel có thể bị hủy kích hoạt cho các cơ sở dữ liệu, lược đồ và bảng riêng lẻ bằng cách chỉ định DATA_RETENTION_TIME_IN_DAYS với giá trị 0 cho đối tượng. Tuy nhiên, nếu DATA_RETENTION_TIME_IN_DAYS được đặt thành giá trị 0 và MIN_DATA_RETENTION_TIME_IN_DAYS được đặt ở cấp độ tài khoản và lớn hơn 0, thì cài đặt giá trị cao hơn sẽ được ưu tiên.
Chú ý: Trước khi đặt DATA_RETENTION_TIME_IN_DAYS thành 0 cho bất kỳ đối tượng nào, hãy cân nhắc xem bạn có muốn hủy kích hoạt Time Travel cho đối tượng đó hay không, đặc biệt là liên quan đến việc khôi phục đối tượng nếu nó bị xóa. Khi một đối tượng không có thời gian lưu giữ bị xóa, bạn sẽ không thể khôi phục đối tượng đó.
Theo nguyên tắc chung, chúng tôi khuyên bạn nên duy trì giá trị (ít nhất) là 1 ngày cho bất kỳ đối tượng nào.
Nếu thời gian lưu giữ Time Travel được đặt thành 0, bất kỳ dữ liệu nào được sửa đổi hoặc xóa sẽ được chuyển vào Fail-safe (đối với bảng vĩnh viễn) hoặc bị xóa (đối với bảng tạm thời) bởi một quy trình nền. Điều này có thể mất một thời gian ngắn để hoàn thành. Trong thời gian đó, TIME_TRAVEL_BYTES trong số liệu lưu trữ bảng có thể chứa giá trị khác không ngay cả khi thời gian lưu giữ Time Travel là 0 ngày.
3. Chỉ Định Thời Gian Lưu Giữ Dữ Liệu Cho Một Đối Tượng
Theo mặc định, thời gian lưu giữ tối đa là 1 ngày (một khoảng thời gian 24 giờ). Với Snowflake Enterprise Edition (và cao hơn), giá trị mặc định cho tài khoản của bạn có thể được đặt thành bất kỳ giá trị nào lên đến 90 ngày:
- Khi tạo bảng, lược đồ hoặc cơ sở dữ liệu, giá trị mặc định của tài khoản có thể bị ghi đè bằng cách sử dụng tham số DATA_RETENTION_TIME_IN_DAYS trong lệnh.
- Nếu thời gian lưu giữ được chỉ định cho cơ sở dữ liệu hoặc lược đồ, thời gian đó sẽ được kế thừa theo mặc định cho tất cả các đối tượng được tạo trong cơ sở dữ liệu/lược đồ.
Thời gian lưu giữ tối thiểu có thể được đặt trên tài khoản bằng cách sử dụng tham số MIN_DATA_RETENTION_TIME_IN_DAYS. Nếu tham số này được đặt ở cấp độ tài khoản, thời gian lưu giữ dữ liệu cho một đối tượng được xác định bởi MAX(DATA_RETENTION_TIME_IN_DAYS, MIN_DATA_RETENTION_TIME_IN_DAYS).
4. Kiểm Tra Thời Gian Lưu Giữ Dữ Liệu Cho Một Đối Tượng
Để kiểm tra thời gian lưu giữ hiện tại cho một bảng, lược đồ hoặc cơ sở dữ liệu, bạn có thể kiểm tra giá trị của cột retention_time trong đầu ra của lệnh SHOW tương ứng, chẳng hạn như SHOW TABLES, SHOW SCHEMAS hoặc SHOW DATABASES.
Đối với các đối tượng có nguồn gốc từ bảng, lược đồ hoặc cơ sở dữ liệu, chẳng hạn như chế độ xem được hiện thực hóa, bạn có thể kiểm tra thời gian lưu giữ của các đối tượng mẹ.
Đối với các luồng, bạn có thể kiểm tra giá trị của cột stale_after trong đầu ra từ lệnh SHOW STREAMS.
Để bao gồm thông tin về các đối tượng đã bị xóa, hãy bao gồm mệnh đề HISTORY với lệnh SHOW.
Ví dụ sau đây cho thấy cách bạn có thể kiểm tra thời gian lưu giữ của một số đối tượng nhất định bằng cách lọc đầu ra của các lệnh SHOW.
Ví dụ sau kiểm tra thời gian lưu giữ cho các bảng được đặt tên cụ thể:
SHOW TABLES;
-- ... đầu ra bị bỏ qua ...
SELECT "name", "retention_time"
FROM TABLE(RESULT_SCAN(-1))
WHERE "name" IN ('my_table1', 'my_table2');Ví dụ sau kiểm tra các lược đồ mà Time Travel đã tắt:
SHOW SCHEMAS;
-- ... đầu ra bị bỏ qua ...
SELECT "name", "retention_time"
FROM TABLE(RESULT_SCAN(-1))
WHERE "retention_time" = 0;Ví dụ sau kiểm tra các cơ sở dữ liệu có thời gian lưu giữ lớn hơn giá trị mặc định. Kết quả bao gồm các cơ sở dữ liệu đã bị xóa.
SHOW DATABASES HISTORY;
-- ... đầu ra bị bỏ qua ...
SELECT "name", "retention_time", "dropped_on"
FROM TABLE(RESULT_SCAN(-1))
WHERE "retention_time" > 1;5. Thay Đổi Thời Gian Lưu Giữ Dữ Liệu Cho Một Đối Tượng
Nếu bạn thay đổi thời gian lưu giữ dữ liệu cho một bảng, thời gian lưu giữ mới sẽ ảnh hưởng đến tất cả dữ liệu đang hoạt động, cũng như bất kỳ dữ liệu nào hiện có trong Time Travel. Tác động phụ thuộc vào việc bạn tăng hay giảm thời gian:
-
Tăng thời gian lưu giữ: Khiến dữ liệu hiện có trong Time Travel được giữ lại trong khoảng thời gian dài hơn.
Ví dụ: nếu bạn có một bảng có thời gian lưu giữ 10 ngày và tăng thời gian lên 20 ngày, dữ liệu lẽ ra đã bị xóa sau 10 ngày hiện được giữ lại thêm 10 ngày trước khi chuyển vào Fail-safe.
Lưu ý rằng điều này không áp dụng cho bất kỳ dữ liệu nào cũ hơn 10 ngày và đã chuyển vào Fail-safe.
-
Giảm thời gian lưu giữ: Giảm lượng thời gian dữ liệu được giữ lại trong Time Travel:
-
Đối với dữ liệu đang hoạt động được sửa đổi sau khi giảm thời gian lưu giữ, thời gian ngắn hơn mới sẽ được áp dụng.
-
Đối với dữ liệu hiện có trong Time Travel:
- Nếu dữ liệu vẫn nằm trong khoảng thời gian ngắn hơn mới, nó sẽ vẫn còn trong Time Travel.
- Nếu dữ liệu nằm ngoài khoảng thời gian mới, nó sẽ chuyển vào Fail-safe.
Ví dụ: nếu bạn có một bảng có thời gian lưu giữ 10 ngày và bạn giảm thời gian xuống 1 ngày, dữ liệu từ ngày 2 đến ngày 10 sẽ được chuyển vào Fail-safe, chỉ để lại dữ liệu từ ngày 1 có thể truy cập thông qua Time Travel.
Tuy nhiên, quá trình di chuyển dữ liệu từ Time Travel vào Fail-safe được thực hiện bởi một quy trình nền, vì vậy thay đổi không hiển thị ngay lập tức. Snowflake đảm bảo rằng dữ liệu sẽ được di chuyển, nhưng không chỉ định thời điểm quá trình sẽ hoàn thành; cho đến khi quá trình nền hoàn thành, dữ liệu vẫn có thể truy cập thông qua Time Travel.
-
Lưu ý: Nếu bạn thay đổi thời gian lưu giữ dữ liệu cho cơ sở dữ liệu hoặc lược đồ, thay đổi chỉ ảnh hưởng đến các đối tượng đang hoạt động có trong cơ sở dữ liệu hoặc lược đồ. Bất kỳ đối tượng nào đã bị xóa (ví dụ: bảng) vẫn không bị ảnh hưởng.
Ví dụ: nếu bạn có một lược đồ s1 có thời gian lưu giữ 90 ngày và bảng t1 nằm trong lược đồ s1, bảng t1 sẽ kế thừa thời gian lưu giữ 90 ngày. Nếu bạn xóa bảng s1.t1, t1 sẽ được giữ lại trong Time Travel trong 90 ngày. Sau đó, nếu bạn thay đổi thời gian lưu giữ dữ liệu của lược đồ thành 1 ngày, thời gian lưu giữ cho bảng t1 đã xóa sẽ không thay đổi. Bảng t1 sẽ vẫn được giữ lại trong Time Travel trong 90 ngày.
Để thay đổi thời gian lưu giữ của một đối tượng đã xóa, bạn phải bỏ xóa đối tượng, sau đó thay đổi thời gian lưu giữ của nó.
Để thay đổi thời gian lưu giữ cho một đối tượng, hãy sử dụng lệnh ALTER thích hợp. Ví dụ: để thay đổi thời gian lưu giữ cho một bảng:
CREATE TABLE mytable(col1 NUMBER, col2 DATE) DATA_RETENTION_TIME_IN_DAYS=90;
ALTER TABLE mytable SET DATA_RETENTION_TIME_IN_DAYS=30;Chú ý: Thay đổi thời gian lưu giữ cho tài khoản của bạn hoặc các đối tượng riêng lẻ sẽ thay đổi giá trị cho tất cả các đối tượng cấp thấp hơn không có thời gian lưu giữ được đặt rõ ràng. Ví dụ:
- Nếu bạn thay đổi thời gian lưu giữ ở cấp độ tài khoản, tất cả các cơ sở dữ liệu, lược đồ và bảng không có thời gian lưu giữ rõ ràng sẽ tự động kế thừa thời gian lưu giữ mới.
- Nếu bạn thay đổi thời gian lưu giữ ở cấp độ lược đồ, tất cả các bảng trong lược đồ không có thời gian lưu giữ rõ ràng sẽ kế thừa thời gian lưu giữ mới.
Hãy ghi nhớ điều này khi thay đổi thời gian lưu giữ cho tài khoản của bạn hoặc bất kỳ đối tượng nào trong tài khoản của bạn vì thay đổi có thể gây ra hậu quả Time Travel mà bạn không lường trước hoặc dự định. Đặc biệt, chúng tôi không khuyên bạn nên thay đổi thời gian lưu giữ thành 0 ở cấp độ tài khoản.
5.1. Các Container Đã Xóa Và Kế Thừa Thời Gian Lưu Giữ Đối Tượng
Hiện tại, khi một cơ sở dữ liệu bị xóa, thời gian lưu giữ dữ liệu cho các lược đồ hoặc bảng con, nếu được đặt rõ ràng khác với thời gian lưu giữ của cơ sở dữ liệu, sẽ không được tuân thủ. Các lược đồ hoặc bảng con được giữ lại trong cùng khoảng thời gian với cơ sở dữ liệu.
Tương tự, khi một lược đồ bị xóa, thời gian lưu giữ dữ liệu cho các bảng con, nếu được đặt rõ ràng khác với thời gian lưu giữ của lược đồ, sẽ không được tuân thủ. Các bảng con được giữ lại trong cùng khoảng thời gian với lược đồ.
Để tuân thủ thời gian lưu giữ dữ liệu cho các đối tượng con này (lược đồ hoặc bảng), hãy xóa chúng rõ ràng trước khi bạn xóa cơ sở dữ liệu hoặc lược đồ.
6. Truy Vấn Dữ Liệu Lịch Sử
Khi bất kỳ thao tác DML nào được thực hiện trên một bảng, Snowflake sẽ giữ lại các phiên bản trước của dữ liệu bảng trong một khoảng thời gian xác định. Điều này cho phép truy vấn các phiên bản trước của dữ liệu bằng cách sử dụng mệnh đề AT | BEFORE.
Mệnh đề này hỗ trợ truy vấn dữ liệu chính xác tại hoặc ngay trước một điểm được chỉ định trong lịch sử của bảng trong thời gian lưu giữ. Điểm được chỉ định có thể dựa trên thời gian (ví dụ: dấu thời gian hoặc độ lệch thời gian so với hiện tại) hoặc có thể là ID cho một câu lệnh đã hoàn thành (ví dụ: SELECT hoặc INSERT).
Ví dụ:
-
Truy vấn sau chọn dữ liệu lịch sử từ một bảng kể từ ngày và giờ được biểu thị bằng dấu thời gian được chỉ định:
SELECT * FROM my_table AT(TIMESTAMP => 'Wed, 26 Jun 2024 09:20:00 -0700'::timestamp_tz); -
Truy vấn sau chọn dữ liệu lịch sử từ một bảng kể từ 5 phút trước:
SELECT * FROM my_table AT(OFFSET => -60*5); -
Truy vấn sau chọn dữ liệu lịch sử từ một bảng cho đến, nhưng không bao gồm bất kỳ thay đổi nào được thực hiện bởi câu lệnh được chỉ định:
SELECT * FROM my_table BEFORE(STATEMENT => '8e5d0ca9-005e-44e6-b858-a8f5b37c5726');
Lưu ý: Nếu TIMESTAMP, OFFSET hoặc STATEMENT được chỉ định trong mệnh đề AT | BEFORE nằm ngoài thời gian lưu giữ dữ liệu cho bảng, truy vấn sẽ không thành công và trả về lỗi.
7. Sao Chép Các Đối Tượng Lịch Sử
Ngoài các truy vấn, mệnh đề AT | BEFORE có thể được sử dụng với từ khóa CLONE trong lệnh CREATE cho một bảng, lược đồ hoặc cơ sở dữ liệu để tạo một bản sao logic của đối tượng tại một điểm được chỉ định trong lịch sử của đối tượng. Nếu bạn không chỉ định một thời điểm, bản sao sẽ mặc định là trạng thái của đối tượng kể từ bây giờ (giá trị CURRENT_TIMESTAMP).
Ví dụ:
Lưu ý: Thao tác sao chép cho cơ sở dữ liệu hoặc lược đồ không thành công:
-
Nếu thời gian Time Travel được chỉ định vượt quá thời gian lưu giữ của bất kỳ đối tượng con hiện tại nào (ví dụ: một bảng) của thực thể.
Là một giải pháp cho các đối tượng con đã bị xóa khỏi Time Travel, hãy sử dụng tham số IGNORE TABLES WITH INSUFFICIENT DATA RETENTION của CREATE
-
Nếu thời gian Time Travel được chỉ định bằng hoặc trước thời điểm đối tượng được tạo.
8. Xóa Và Khôi Phục Các Đối Tượng
Các phần sau đây giải thích các cân nhắc về Time Travel cho các lệnh DROP, SHOW và UNDROP.
8.1. Xóa Các Đối Tượng
Khi một bảng, lược đồ hoặc cơ sở dữ liệu bị xóa, nó không bị ghi đè hoặc xóa ngay lập tức khỏi hệ thống. Thay vào đó, nó được giữ lại trong thời gian lưu giữ dữ liệu cho đối tượng, trong thời gian đó đối tượng có thể được khôi phục. Khi các đối tượng đã xóa được chuyển sang Fail-safe, bạn không thể khôi phục chúng.
Để xóa một sổ ghi chép, bảng, lược đồ hoặc cơ sở dữ liệu, hãy sử dụng các lệnh sau:
Lưu ý: Sau khi xóa một đối tượng, việc tạo một đối tượng có cùng tên không khôi phục đối tượng đó. Thay vào đó, nó tạo ra một phiên bản mới của đối tượng. Phiên bản ban đầu, đã xóa vẫn khả dụng và có thể được khôi phục.
Khôi phục một đối tượng đã xóa sẽ khôi phục đối tượng tại chỗ (tức là nó không tạo ra một đối tượng mới).
8.2. Liệt Kê Các Đối Tượng Đã Xóa
Các đối tượng đã xóa có thể được liệt kê bằng cách sử dụng các lệnh sau với từ khóa HISTORY được chỉ định:
Ví dụ:
SHOW TABLES HISTORY LIKE 'load%' IN mytestdb.myschema;
SHOW SCHEMAS HISTORY IN mytestdb;
SHOW DATABASES HISTORY;Đầu ra bao gồm tất cả các đối tượng đã xóa và một cột DROPPED_ON bổ sung, hiển thị ngày và giờ đối tượng bị xóa. Nếu một đối tượng đã bị xóa nhiều lần, mỗi phiên bản của đối tượng sẽ được bao gồm dưới dạng một hàng riêng biệt trong đầu ra.
Lưu ý: Sau khi thời gian lưu giữ cho một đối tượng đã trôi qua và đối tượng đã bị xóa, nó sẽ không còn được hiển thị trong đầu ra SHOW HISTORY.
8.3. Khôi Phục Các Đối Tượng
Một đối tượng đã xóa chưa bị xóa khỏi hệ thống (tức là đối tượng được hiển thị trong đầu ra SHOW HISTORY) có thể được khôi phục bằng cách sử dụng các lệnh sau:
Gọi UNDROP sẽ khôi phục đối tượng về trạng thái gần đây nhất của nó trước khi lệnh DROP được ban hành.
Ví dụ:
UNDROP TABLE mytable;
UNDROP SCHEMA myschema;
UNDROP DATABASE mydatabase;
UNDROP NOTEBOOK mynotebook;Lưu ý: Nếu một đối tượng có cùng tên đã tồn tại, UNDROP sẽ không thành công. Bạn phải đổi tên đối tượng hiện có, điều này sẽ cho phép bạn khôi phục phiên bản trước của đối tượng.
8.4. Các Yêu Cầu Về Kiểm Soát Truy Cập Và Giải Quyết Tên
Tương tự như việc xóa một đối tượng, người dùng phải có đặc quyền OWNERSHIP cho một đối tượng để khôi phục nó. Ngoài ra, người dùng phải có đặc quyền CREATE trên loại đối tượng cho cơ sở dữ liệu hoặc lược đồ nơi đối tượng đã xóa sẽ được khôi phục.
Việc khôi phục bảng và lược đồ chỉ được hỗ trợ trong lược đồ hiện tại hoặc cơ sở dữ liệu hiện tại, ngay cả khi tên đối tượng đủ điều kiện được chỉ định.
8.5. Ví Dụ: Xóa Và Khôi Phục Một Bảng Nhiều Lần
Trong ví dụ sau, lược đồ mytestdb.public chứa hai bảng: loaddata1 và proddata1. Bảng loaddata1 bị xóa và tạo lại hai lần, tạo ra ba phiên bản của bảng:
- Phiên bản hiện tại
- Phiên bản đã xóa thứ hai (gần đây nhất)
- Phiên bản đã xóa đầu tiên
Ví dụ sau đó minh họa cách khôi phục hai phiên bản đã xóa của bảng:
- Đầu tiên, bảng hiện tại có cùng tên được đổi tên thành
loaddata3. Điều này cho phép khôi phục phiên bản gần đây nhất của bảng đã xóa, dựa trên dấu thời gian. - Sau đó, phiên bản đã xóa gần đây nhất của bảng được khôi phục.
- Bảng đã khôi phục được đổi tên thành
loaddata2để cho phép khôi phục phiên bản đầu tiên của bảng đã xóa. - Cuối cùng, phiên bản đầu tiên của bảng đã xóa được khôi phục.
SHOW TABLES HISTORY;
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | dropped_on |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB | PUBLIC | TABLE | | | 48 | 16248 | PUBLIC | 1 | [NULL] |
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB | PUBLIC | TABLE | | | 12 | 4096 | PUBLIC | 1 | [NULL] |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
DROP TABLE loaddata1;
SHOW TABLES HISTORY;
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | dropped_on |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB | PUBLIC | TABLE | | | 12 | 4096 | PUBLIC | 1 | [NULL] |
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB | PUBLIC | TABLE | | | 48 | 16248 | PUBLIC | 1 | Fri, 13 May 2016 19:04:46 -0700 |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
CREATE TABLE loaddata1 (c1 number);
INSERT INTO loaddata1 VALUES (1111), (2222), (3333), (4444);
DROP TABLE loaddata1;
CREATE TABLE loaddata1 (c1 varchar);
SHOW TABLES HISTORY;
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | dropped_on |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Fri, 13 May 2016 19:06:01 -0700 | LOADDATA1 | MYTESTDB | PUBLIC | TABLE | | | 0 | 0 | PUBLIC | 1 | [NULL] |
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB | PUBLIC | TABLE | | | 12 | 4096 | PUBLIC | 1 | [NULL] |
| Fri, 13 May 2016 19:05:32 -0700 | LOADDATA1 | MYTESTDB | PUBLIC | TABLE | | | 4 | 4096 | PUBLIC | 1 | Fri, 13 May 2016 19:05:51 -0700 |
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB | PUBLIC | TABLE | | | 48 | 16248 | PUBLIC | 1 | Fri, 13 May 2016 19:04:46 -0700 |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
ALTER TABLE loaddata1 RENAME TO loaddata3;
UNDROP TABLE loaddata1;
SHOW TABLES HISTORY;
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | dropped_on |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Fri, 13 May 2016 19:05:32 -0700 | LOADDATA1 | MYTESTDB | PUBLIC | TABLE | | | 4 | 4096 | PUBLIC | 1 | [NULL] |
| Fri, 13 May 2016 19:06:01 -0700 | LOADDATA3 | MYTESTDB | PUBLIC | TABLE | | | 0 | 0 | PUBLIC | 1 | [NULL] |
| Tue, 17 Mar 2016 17:51:30 -0700 | PRODDATA1 | MYTESTDB | PUBLIC | TABLE | | | 12 | 4096 | PUBLIC | 1 | [NULL] |
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB | PUBLIC | TABLE | | | 48 | 16248 | PUBLIC | 1 | Fri, 13 May 2016 19:04:46 -0700 |
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
ALTER TABLE loaddata1 RENAME TO loaddata2;
UNDROP TABLE loaddata1;
+---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------+
| created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | dropped_on |
|---------------------------------+-----------+---------------+-------------+-------+---------+------------+------+-------+--------+----------------+---------------------------------|
| Tue, 17 Mar 2016 17:41:55 -0700 | LOADDATA1 | MYTESTDB | PUBLIC | TABLE | | | 48 | 16248 | PUBLIC | 1 | [NULL] |
| Fri, 13 May 2016 19:05:32 -0700 | LOADDATA2 | MYTESTDB | PUBLIC | TABLE | | | 4 | 4096 | PUBLIC | 1 | [NULL] |
| Fri, 13 May 2016 19:06:01 -0700 | LOADDATA3 | MYTESTDB | PUBLIC | TABLE | | | 0 | 0 | PUBLIC | 1 | [NULL] |
| Tue, 17 Mar 20