You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/azure-data-studio/tutorial-sql-editor.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -61,11 +61,11 @@ Azure Data Studio provides many built-in T-SQL snippets for quickly creating sta
61
61
62
62
2. Type **sql** in the editor, arrow down to **sqlCreateStoredProcedure**, and press the *Tab* key (or *Enter*) to load the create stored procedure snippet.
65
65
66
66
3. The create stored procedure snippet has two fields set up for quick edit, *StoredProcedureName* and *SchemaName*. Select *StoredProcedureName*, right-click, and select **Change All Occurrences**. Now type *getCustomer* and all *StoredProcedureName* entries change to *getCustomer*.
69
69
70
70
5. Change all occurrences of *SchemaName* to *dbo*.
71
71
6. The snippet contains placeholder parameters and body text that needs updating. The *EXECUTE* statement also contains placeholder text because it doesn't know how many parameters the procedure will have. For this tutorial update the snippet so it looks like the following code:
Copy file name to clipboardExpand all lines: docs/database-engine/install-windows/change-the-database-compatibility-mode-and-use-the-query-store.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,7 +40,7 @@ The upgrade process to enable new query processor functionality is related to th
40
40
41
41
The recommended workflow for upgrading the query processor to the latest version of the code is documented in the [Keep performance stability during the upgrade to newer SQL Server section of Query Store Usage Scenarios](../../relational-databases/performance/query-store-usage-scenarios.md#CEUpgrade), as seen below.
![Diagram showing the recommended workflow for upgrading the query processor to the latest version of the code.](../../relational-databases/performance/media/query-store-usage-5.png"query-store-usage-5")
44
44
45
45
Starting with [!INCLUDE[ssManStudioFull](../../includes/ssmanstudiofull-md.md)] v18, users can be guided through the recommended workflow using the Query Tuning Assistant. For more information, see [Upgrading Databases by using the Query Tuning Assistant](../../relational-databases/performance/upgrade-dbcompat-using-qta.md).
42
42
43
43
>[!NOTE]
44
44
> The numbers in the path *nnn* correspond to the version of SQL being installed. In the above picture, SQL 2017 was installed, so the folder is 140. For SQL 2016, the folder would be 130, and for SQL 2014 the folder would be 120.
51
51
52
52
This diagram shows all the components participating in a typical VSS snapshot activity. In such a scenario, SQL Server (including the SQL writer) is acting as a writer in one of the Writer boxes. Other such writers might be Exchange Server, etc.
73
73
74
74
3. In the **Server name** box, type the name of the instance of the [!INCLUDE[ssDE](../includes/ssde-md.md)]. For the default instance of SQL Server, the server name is the computer name. For a named instance of SQL Server, the server name is the _\<computer_name\>_**\\**_\<instance_name\>_, such as **ACCTG_SRVR\SQLEXPRESS**. The following screenshot shows connecting to the default (un-named) instance of [!INCLUDE[ssNoVersion_md](../includes/ssnoversion-md.md)] on a computer named 'PracticeComputer'. The user logged into Windows is Mary from the Contoso domain. When using Windows Authentication you cannot change the user name.
Copy file name to clipboardExpand all lines: docs/relational-databases/tables/manage-retention-of-historical-data-in-system-versioned-temporal-tables.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -174,7 +174,7 @@ A partitioning configuration task creates the initial partitioning configuration
174
174
175
175
The following picture shows initial partitioning configuration to keep 6 months of data.
![Diagram showing initial partitioning configuration to keep six months of data.](../../relational-databases/tables/media/partitioning.png"Partitioning")
178
178
179
179
> [!NOTE]
180
180
> See Performance considerations with table partitioning below for the performance implications of using RANGE LEFT versus RANGE RIGHT when configuring partitioning.
@@ -183,7 +183,7 @@ The first and last partition are "open" on lower and upper boundaries respective
183
183
184
184
The following picture illustrates the recurring partition maintenance tasks (see detailed steps below).
321
321
322
322
When you define a partition function as RANGE LEFT, the specified values are the upper boundaries of the partitions. When you use RANGE RIGHT, the specified values are the lower boundaries of the partitions. When you use the MERGE RANGE operation to remove a boundary from the partition function definition, the underlying implementation also removes the partition which contains the boundary. If that partition is not empty, data will be moved to the partition that is result of MERGE RANGE operation.
323
323
@@ -338,7 +338,7 @@ The cleanup logic is the same for every temporal table, so it can be automated r
338
338
339
339
The following diagram illustrates how your cleanup logic should be organized for a single table to reduce impact on the running workloads.
342
342
343
343
Here are some high-level guidelines for implementing the process. Schedule cleanup logic to run every day and iterate over all temporal tables that need data cleanup. Use SQL Server Agent or different tool to schedule this process:
Copy file name to clipboardExpand all lines: docs/relational-databases/tables/temporal-table-usage-scenarios.md
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ Temporal system-versioned tables allow you to plan for data audit scenarios in t
27
27
The following diagram shows an Employee table scenario with the data sample including current (marked with blue color) and historical row versions (marked with grey color).
28
28
The right-hand portion of the diagram visualizes row versions on time axis and what are the rows you select with different types of querying on temporal table with or without SYSTEM_TIME clause.
![Diagram showing simplified data model used for inventory management.](../../relational-databases/tables/media/temporalusageinmemory.png"TemporalUsageInMemory")
174
174
175
175
The following code example creates ProductInventory as an in-memory system-versioned temporal table with a clustered columnstore index on the history table (which actually replaces the row-store index created by default):
176
176
@@ -256,7 +256,7 @@ END;
256
256
257
257
The spUpdateInventory stored procedure either inserts a new product in the inventory or updates the product quantity for the particular location. The business logic is very simple and focused on maintaining the latest state accurate all the time by incrementing / decrementing the Quantity field through table update, while system-versioned tables transparently add history dimension to the data, as depicted on the diagram below.
![Diagram showing Temporal Usage with current usage In-Memory and historic usage in a clustered columnstore.](../../relational-databases/tables/media/temporalusageinmemory2b.png"TemporalUsageInMemory2b")
260
260
261
261
Now, querying of the latest state can be performed efficiently from the natively compiled module:
262
262
@@ -290,7 +290,7 @@ SELECT * FROM vw_GetProductInventoryHistory
290
290
291
291
The diagram below shows the data history for one product which can be easily rendered importing the view above in the Power Query, Power BI or similar business intelligence tool:
![Diagram showing the data history for one product.](../../relational-databases/tables/media/producthistoryovertime.png"ProductHistoryOverTime")
294
294
295
295
Temporal tables can be used in this scenario to perform other types of time travel analysis, such as reconstructing the state of the inventory AS OF any point in time in the past or comparing snapshots that belong to different moments in time.
296
296
@@ -343,7 +343,7 @@ SELECT * FROM vw_ProductInventoryDetails
343
343
344
344
The following picture shows the execution plan generated for the SELECT query. This illustrates that all complexity of dealing with temporal relations is fully handled by the SQL Server engine:
![Diagram showing the execution plan generated for the SELECT query illustrating that all complexity of dealing with temporal relations is fully handled by the SQL Server engine.](../../relational-databases/tables/media/asofexecutionplan.png"ASOFExecutionPlan")
347
347
348
348
Use the following code to compare state of product inventory between two points in time (a day ago and a month ago):
349
349
@@ -385,7 +385,7 @@ CREATE TABLE [dbo].[Product]
385
385
386
386
The following diagram shows the purchases over time:
![Diagram showing the purchases over time.](../../relational-databases/tables/media/temporalanomalydetection.png"TemporalAnomalyDetection")
389
389
390
390
Assuming that during the regular days number of purchased products has small variance, the following query identifies singleton outliers - samples which difference compared to their immediate neighbors is significant (2x), while surrounding samples do not differ significantly (less than 20%):
391
391
@@ -461,7 +461,7 @@ No additional code is required to maintain SCD during the data warehouse loading
461
461
462
462
The following illustration shows how you can use Temporal Tables in a simple scenario involving 2 SCDs (DimLocation and DimProduct) and one fact table.
![Diagram showing how you can use Temporal Tables in a simple scenario involving 2 SCDs (DimLocation and DimProduct) and one fact table.](../../relational-databases/tables/media/temporalscd.png"TemporalSCD")
465
465
466
466
In order to use above SCDs in reports, you need to effectively adjust querying. For example, you might want to calculate the total sales amount and the average number of sold products per capita for the last six months. Note that both metrics requires the correlation of data from the fact table and dimensions that might have changed their attributes important for the analysis (DimLocation.NumOfCustomers, DimProduct.UnitPrice). The following query properly calculates the required metrics:
467
467
@@ -534,13 +534,13 @@ This stored procedure takes @EmployeeID and @versionNumber as input parameters.
534
534
535
535
The following picture shows state of the row before and after the procedure invocation. Red rectangle marks current row version that is incorrect, while green rectangle marks correct version from the history.
![Screenshot showing the state of the row before and after the procedure invocation](../../relational-databases/tables/media/temporalusagerepair1.png"TemporalUsageRepair1")
![Screenshot showing the corrected row.](../../relational-databases/tables/media/temporalusagerepair2.png"TemporalUsageRepair2")
544
544
545
545
This repair stored procedure can be defined to accept an exact timestamp instead of row version. It will restore row to any version that was active for the point in time provided (i.e. AS OF point in time).
546
546
@@ -562,11 +562,11 @@ UPDATE Employee
562
562
563
563
For the same data sample the following picture illustrates repair scenario with time condition. Highlighted are @asOf parameter, selected row in the history that was actual at the provided point in time and new row version in the current table after repair operation:
![Screenshot showing the repair scenario with time condition.](../../relational-databases/tables/media/temporalusagerepair3.png"TemporalUsageRepair3")
566
566
567
567
Data correction can become part of automated data loading in data warehousing and reporting systems. If a newly updated value is not correct then, in many scenarios, restoring the previous version from history is good enough mitigation. The following diagram shows how this process can be automated:
Copy file name to clipboardExpand all lines: docs/relational-databases/tables/temporal-tables.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -73,7 +73,7 @@ Real data sources are dynamic and more often than not business decisions rely on
73
73
74
74
The current table contains the current value for each row. The history table contains each previous value for each row, if any, and the start time and end time for the period for which it was valid.
![Diagram showing how a Temporal table works.](../../relational-databases/tables/media/temporal-howworks.PNG"Temporal-HowWorks")
77
77
78
78
The following simple example illustrates a scenario with Employee information in hypothetical HR database:
79
79
@@ -105,7 +105,7 @@ WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));
105
105
106
106
The **SELECT** statement **FROM**_\<table\>_ clause has a new clause **FOR SYSTEM_TIME** with five temporal-specific sub-clauses to query data across the current and history tables. This new **SELECT** statement syntax is supported directly on a single table, propagated through multiple joins, and through views on top of multiple temporal tables.
![Diagram showing how TemporalQuerying works.](../../relational-databases/tables/media/temporal-querying.PNG"Temporal-Querying")
109
109
110
110
The following query searches for row versions for Employee row with EmployeeID = 1000 that were active at least for a portion of period between 1st January of 2014 and 1st January 2015 (including the upper boundary):
0 commit comments