Walking down the memory lane with temporal tables
•Als PPTX, PDF herunterladen•
0 gefällt mir•242 views
Presented @ PHISSUG S01E01 last January 2016. A brief introduction on how SQL Server 2016's temporal table works. Includes creating and querying system versioned tables.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Walking down the memory lane with temporal tables
Ähnlich wie Walking down the memory lane with temporal tables (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Walking down the memory lane with temporal tables
- 1. Walking down the memory lane with Temporal Tables SQL Server 2016 CTP3’s Temporal Tables
- 2. I am Argelo Royce Bautista • 3 Years in the IT Industry • Full-Stackoverflow Developer • Enjoys creating reports (SSRS, Excel, & Power Query)
- 3. What are temporal tables? Temporal Tables allow querying of data from a point in time. SQL Server 2016’s Temporal Table Allows you to maintain versions of the rows based on the time that the user modifies/deletes data. Allows you to query the present and the past data.
- 4. Why Temporal Tables? Understanding business trends over time Tracking data changes over time Auditing all changes to data Maintaining a slowly changing dimension for decision support applications Recovering from accidental data changes and application errors Time Travel Data Audit Slowly Changing Dimensions Repair record- level corruptions
- 5. SQL Server 2016’s Implementation of Temporal Tables No change in programming model New Insights INSERT / BULK INSERT UPDATE DELETE MERGE DML SELECT * FROM temporal Querying CREATE temporal TABLE PERIOD FOR SYSTEM_TIME… ALTER regular_table TABLE ADD PERIOD… DDL FOR SYSTEM_TIME AS OF FROM..TO BETWEEN..AND CONTAINED IN Temporal Querying
- 6. SQL Server 2016’s Implementation of Temporal Tables Temporal table (actual data) Insert / Bulk Insert * Old versions Update */ Delete * History Table
- 7. SQL Server 2016’s Implementation of Temporal Tables Temporal table (actual data) Temporal Queries * (Time travel,etc.) History Table Regular queries (current data) * Include Historical Version
- 9. Considerations and Limitations A temporal table must have a primary key defined History table cannot have constraints; primary key, foreign key, table, or column constraints INSERT and UPDATE statement scan not reference SYSTEM_TIME period columns TRUNCATE TABLE is not supported while SYSTEM_VERSIONING is ON INSTEAD OF triggers not permitted on current and history table, AFTER triggers permitted only on current table REPLICATION usage is limited, some objects/properties are not replicated. Full list of considerations and limitations: https://msdn.microsoft.com/en- us/library/mt604468.aspx
- 10. Questions?
- 11. References: Temporal Tables (CTP2): http://www.slideshare.net/stephanefrechette/back-to- the-future-temporal-table-in-sql-server-2016 Temporal database Concepts: https://en.wikipedia.org/wiki/Temporal_database MSDN Documentation: https://msdn.microsoft.com/en-us/library/dn935015.aspx Considerations and Limitations: https://msdn.microsoft.com/en- us/library/mt604468.aspx Consistency Checks: https://msdn.microsoft.com/en-us/library/mt604464.aspx Further Readings: http://sqlmag.com/sql-server/first-look-system-versioned-temporal-tables-part-1- creating-tables-and-modifying-data http://sqlmag.com/sql-server/first-look-system-versioned-temporal-tables-part-2- querying-data-and-optimization-conside
Hinweis der Redaktion
- Source: https://msdn.microsoft.com/en-us/library/dn935015.aspx How Does Temporal Work? System-versioning for a table is implemented as a pair of tables, a current table and a history table. Within each of these tables, two additional datetime (datetime2 datatype) columns are used to define the period of validity for each record – a system start time (SysStartTime) column and a system end time (SysEndTime) column. The current table contains the current value for each record. The history table contains the each previous value for each record, if any, and the start time and end time for the period for which it was valid. INSERTS: On an INSERT, the system sets the value for the SysStartTime column to the UTC time of the current transaction based on the system clock and assigns the value for the SysEndTime column to the maximum value of 9999-12-31 – this marks the record as open. UPDATES: On an UPDATE, the system stores the previous value of the record in the history table and sets the value for the SysEndTime column to the UTC time of the current transaction based on the system clock. This marks the record as closed, with a period recorded for which the record was valid. In the current table, the record is updated with its new value and the system sets the value for the SysStartTime column to the UTC time for the transaction based on the system clock. The value for the updated record in the current table for the SysEndTime column remains the maximum value of 9999-12-31. DELETES: On a DELETE, the system stores the previous value of the record in the history table and sets the value for the SysEndTime column to the UTC time of the current transaction based on the system clock. This marks this record as closed, with a period recorded for which the previous record was valid. In the current table, the record is removed. Queries of the current table will not return this value. Only queries that deal with history data return data for which a record is closed. MERGE: On a MERGE, MERGE behaves as an INSERT, an UPDATE, or a DELETE based on the condition for each record.
- Prior to SQL Server 2016 CTP 3.0, changing the schema of a temporal table required you to set SYSTEM_VERSIONING = OFF. However, beginning with SQL Server 2016 CTP 3.0, you can now add, drop or alter temporal table columns without changing system-versioning state. When you set SYSTEM_VERSIONING = OFF and do not remove drop the SYSTEM_TIME period, the system will continue to update the period columns for every insert and update operation. Deletes on current table will be permanent. When will we want to turn SYSTEM_VERSIONING OFF This is the list of operations that requires system-versioning to be set to OFF: Removing unnecessary data from history (DELETE or TRUNCATE) Removing data from current table without versioning (DELETE, TRUNCATE) Partition SWITCH OUT from current table Partition SWITCH IN into history table You cannot use direct ALTER for the following schema changes. For these types of changes, set SYSTEM_VERSIONING = OFF. Adding a computed column Adding an IDENTITY column Adding a SPARSE column or changing existing column to be SPARSE when the history table is set to DATA_COMPRESSION = PAGE or DATA_COMPRESSION = ROW, which is the default for the history table. Adding a COLUMN_SET Adding a ROWGUIDCOL column or changing existing column to be ROWGUIDCOL