Think that says it all?
None. SQL Server does not have an equivalent feature.
UPDATE: From SQL Server 2016 on, this information is outdated. See the comments and answers below.
I know this question is quite old, but with SQL Server 2016, Temporal Tables is a feature:
https://learn.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables
Maybe it can help others in case they come to this topic (Searching for something similar to Oracle Flashback feature)
With temporal tables enabled, you can query table AS OF a specific timestamp and retrieve rows as they were in that specific timestamp, just like you were used to do in Oracle:
(SELECT * FROM EMPLOYEE AS OF TIMESTAMP ('13-SEP-04 8:50:58','DD-MON-YY HH24: MI: SS')
Equivalent query in SQL Server for a table with SYSTEM_VERSIONING=ON will be:
SELECT * FROM EMPLOYEE FOR SYSTEM_TIME AS OF '2004-09-01 08:50:58'
To enable SYSTEM_VERSIONING for an existing table with rows you may use the following script:
ALTER TABLE [dbo].[TABLE] ADD [SysStartTime] datetime2(0) GENERATED ALWAYS AS ROW START HIDDEN NOT NULL CONSTRAINT DF_Inventory_SysStartTime DEFAULT '1900-01-01 00:00:00', [SysEndTime] datetime2(0) GENERATED ALWAYS AS ROW END HIDDEN NOT NULL CONSTRAINT DF_Inventory_SysEndTime DEFAULT '9999-12-31 23:59:59', PERIOD FOR SYSTEM_TIME ([SysStartTime], [SysEndTime])
ALTER TABLE [dbo].[TABLE] SET (SYSTEM_VERSIONING = ON);
After enabling SYSTEM_VERSIONING, the History table will show under the table where you enabled versioning:
To Remove SYSTEM_VERSIONING from a table:
ALTER TABLE [dbo].[TABLE] SET (SYSTEM_VERSIONING = OFF);
ALTER TABLE [dbo].[TABLE] DROP PERIOD FOR SYSTEM_TIME;
ALTER TABLE [dbo].[TABLE] DROP COLUMN [SysStartTime], [SysEndTime];
For more info you can visit the following link (or official Microsoft documentation referenced before):
http://www.sqlservercentral.com/articles/SQL+Server+2016/147087/
Closest equivalent is probably Database Snapshots. You can create a database snapshot at the moment of interest and then report against the snapshot. Unlike flashbacks, the moments at which the SQL Server snapshots are taken has to be pre-determined.
On SQL server 2008 you can use Change Data Capture, by this feature you can do a lot more than oracle flash back. (There is a store procedure to revert database on SQL server 2008 if you want i can provide that for you)
Yes, we can use Change Data Capture and Change Tracking
features which are Built in mechanisms in SQL Server and very much
similar to Flashback in Oracle.
When you apply Change Data Capture features on a database table, a mirror of the tracked table is created with the same column structure of the original table, but with additional columns that include the metadata used to summarize the nature of the change in the database table row. The SQL Server DBA can then easily monitor the activity for the logged table using these new audit tables .
Change tracking is a lightweight solution that provides an efficient change tracking mechanism for applications. Typically, to enable applications to query for changes to data in a database and access information that is related to the changes, application developers had to implement custom change tracking mechanisms. Creating these mechanisms usually involved a lot of work and frequently involved using a combination of triggers, timestamp columns, new tables to store tracking information, and custom cleanup processes.
Different types of applications have different requirements for how much information they need about the changes. Applications can use change tracking to answer the following questions about the changes that have been made to a user table:
What rows have changed for a user table?
Only the fact that a row has changed is required, not how many times the row has changed or the values of any intermediate changes.
The latest data can be obtained directly from the table that is being tracked.
Has a row changed?
The fact that a row has changed and information about the change must be available and recorded at the time that the change was made in the same transaction.
For more information on how to use Change Data Capture (CDC) and Change Tracking in SQL Server; please check out Pinal Dave's Post.
Change Tracking
SQL Server 2016 introduced temporal tables aka history tables which enables developers to query data stored in a database table in the past.
I mean developers can provide applications which enables users to display a table's historical data, or the view of a table at a certain time in the past
Related
Looks like SQL Server 2008 and later uses the concept of "temporal tables" to manage table data history:
https://learn.microsoft.com/en-us/sql/relational-databases/tables/temporal-table-usage-scenarios
Looks like the following clause is used to accomplish this:
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.MyTableHistory));
Let's assume that a data model has tables TableX and a TableXHistory and I select the following context menu path to generate a DDL script of TableX:
Script Table as > CREATE to > New Query Editor Window
If the generated SQL script does not have a text reference to "HISTORY_TABLE" then can I say 100% that the history table is not managed as a temporal table? Also, would a temporal table be explicitly displayed in the standard tables directory for the data model? Is there any reason not to use temporal tables in 2018 as opposed to manually created history tables? My first impression is that anyone who creates manual history tables in 2018 is most likely out of date with SQL Server capabilities.
Temporal tables available only from 2016. Technology is not mature yet.
Temporal tables have their own Pros & Cons. Other options should be considered (classic triggers and history table, change data capture, replication, etc.)
The main disadvantages of temporal tables for me:
multiple changes made at the same time are invisible (only one row is returned)
history tables must be located at the same DB
limitation for transactional replication, merge replication is not supported
issues when system time has been changed - no way to know which update was first w/o implementing additional logic (version)
history tables can'be updated w/o disabling versioning
to get net changes you need to query the base table (which is not good).
how to detect which columns are changed? (CDC & triggers can detect that naturally, with temporal it may be very expensive)
...
I have loaded a huge table from SQL Server onto Hive. The mistake I made is I created the table as a Internal table in HIVE. Can anyone suggest any hack so that I can alter the table structure , without dropping the data.
The data is huge and I cant afford to export the data out of source again.
The problem right now, is that since the column orders don't match the SQL server table, a lot of columns display NULL.
Any help will be highly appreciated.
I do not see any problem to use an Alter Table on a internal table. (https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-AlterTable/Partition/Column)
Another - but not recommended - option would be to open your hive metastore(HCatalog) and apply the changes there. Hive reads out the schema information from a relational database (configured during the Hadoop setup, default is MySQL). In this MySQL you can try to change some settings. However, this is not recommended as with a mistake, you can screw your whole Hive databases.
The safest way is creating a new table and using the existing as a source
create table new_table
as
select
[...]
from existing_table
I have a SQL Server 2008 database. I need to capture Insert/Update/Delete operations on every table in the DB, take the affected primary key and insert into another table ChangeLog. ChangeLog needs capture the PK, source table, operation type.
I don't want to write triggers for every table. Whats the simplest way to do it?
Use case : I connect to SQL Server from Solr. The change log is used for delta import.
I'd start by taking a look at SQL Server Change Tracking and see whether it'll do what you need. It's built in and simple enough to access:
Change Tracking Overview
You don't want to write a trigger for every table because you think it is hard.
Query for a list of each table
Query for each table's primary key
Create a trigger script for add, update and delete to write to the ChangeLog table using the data for each table and primary key.
It's really not that hard to build this script and apply it to your database. If you can write it for one table, you can automatically build scripts for each table. With an error check (does trigger exist), you can run this as new tables are added.
I am looking for information about my table history,
I have to know the time that specific row was inserted
is there someway to know it?
thanks.
Using Triggers
A Datetime column in that table and an After Insert,Update Trigger
which updates that column to GETDATE().
This will only give you the details about the very last
change(update/Insert).
CDC
Change Data Capture (CDC) was introduced in SQL Server 2008. Change
Data Capture records INSERTs, UPDATEs, and DELETEs applied to SQL
Server tables, and makes a record available of what changed, where,
and when, in simple relational ‘change tables’.
These "Change Tables" contain columns that reflect the column
structure of the source table you have chosen to track, along with the
metadata needed to understand the changes that have been made.
Read here more about CDC
Also it is only supported in Datacenter & Enterprise edition.
I have a form with data. Any changes or insertion , those data should be updated in tow different tables like name, salary in one table and address, mail id in another table.
Like the example above i have several columns in both tables.
Now i want to audit the table. So i think i have to create a view for the two tables and set up a trigger for the view. Is it correct?.
And also i need to know only the affected columns. How to get the only affected columns?
Please suggest me a solution.
Thanks!!
There are lots of ways to let the system handle all that grunt work for you - depending on the SQL Server version you're using:
How to: Use SQL Server Change Tracking (as of SQL Server 2008)
Introduction to SQL Server change tracking
Understanding SQL Server Audit (as of SQL Server 2008 R2)
Articles for SQL Server Auditing (various versions)
If you really must handle all the work yourself, you need to get familiarized with triggers - read up on them in Data Points: Exploring SQL Server Triggers.
Inside your trigger code, you have two "pseudo-tables":
Inserted is the table holding the values being inserted (in an INSERT trigger) or the new values (in an UPDATE trigger)
Deleted is the table holding the values being deleted (in a DELETE trigger) or the old values (in an UPDATE trigger)
With those two pseudo-tables, you can get access to all data you might need.