How it works . . .

1. The first thing the client will do is connect directly to the ADW. Since the connection does not have an authorization token, it is redirected to AAD
2. Once the user is authenticated to AAD (SSMS is handling this process), a token is returned to the client
3. Now that the client has a valid token they (SSMS) will return to the ADW login and provide the token
4. Access is granted

The DW in use is a DW500 Gen 1 All statements were executed in xlrgRC The business case here is we want to upgrade the shipping priority for all orders placed last week. For this example the week in question will be 1998-07-24 - 1998-07-31 We will be using the [orders] table with CCI, hash distributed on o_orderkey, and partitioned on o_orderdate by month. DDL: CREATE TABLE [dbo].[orders_part] ( [o_orderkey] bigint NULL, [o_custkey] bigint NULL, [o_orderstatus] char(1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [o_totalprice] decimal(15, 2) NULL, [o_orderdate] date NULL, [o_orderpriority] char(15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [o_clerk] char(15) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [o_shippriority] int NULL, [o_comment] varchar(79) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ) WITH (CLUSTERED COLUMNSTORE INDEX, DISTRIBUTION = HASH([o_orderkey]), PARTITION ([o_orderdate] RANGE RIGHT FOR VALUES ('Jan 1 1992', 'Feb 1 1992', 'Mar 1 1992', 'Apr 1 1992', 'May 1 1992', 'Jun 1 1992', 'Jul 1 1992', 'Aug 1 1992', 'Sep 1 1992', 'Oct 1 1992', 'Nov 1 1992', 'Dec 1 1992', 'Jan 1 1993', 'Feb 1 1993', 'Mar 1 1993', 'Apr 1 1993', 'May 1 1993', 'Jun 1 1993', 'Jul 1 1993', 'Aug 1 1993', 'Sep 1 1993', 'Oct 1 1993', 'Nov 1 1993', 'Dec 1 1993', 'Jan 1 1994', 'Feb 1 1994', 'Mar 1 1994', 'Apr 1 1994', 'May 1 1994', 'Jun 1 1994', 'Jul 1 1994', 'Aug 1 1994', 'Sep 1 1994', 'Oct 1 1994', 'Nov 1 1994', 'Dec 1 1994', 'Jan 1 1995', 'Feb 1 1995', 'Mar 1 1995', 'Apr 1 1995', 'May 1 1995', 'Jun 1 1995', 'Jul 1 1995', 'Aug 1 1995', 'Sep 1 1995', 'Oct 1 1995', 'Nov 1 1995', 'Dec 1 1995', 'Jan 1 1996', 'Feb 1 1996', 'Mar 1 1996', 'Apr 1 1996', 'May 1 1996', 'Jun 1 1996', 'Jul 1 1996', 'Aug 1 1996', 'Sep 1 1996', 'Oct 1 1996', 'Nov 1 1996', 'Dec 1 1996', 'Jan 1 1997', 'Feb 1 1997', 'Mar 1 1997', 'Apr 1 1997', 'May 1 1997', 'Jun 1 1997', 'Jul 1 1997', 'Aug 1 1997', 'Sep 1 1997', 'Oct 1 1997', 'Nov 1 1997', 'Dec 1 1997', 'Jan 1 1998', 'Feb 1 1998', 'Mar 1 1998', 'Apr 1 1998', 'May 1 1998', 'Jun 1 1998', 'Jul 1 1998', 'Aug 1 1998'))); To executed the update we simply run the following command: UPDATE orders_part SET o_shippriority = 1 WHERE o_orderdate BETWEEN '1998-07-24' AND '1998-07-31' This statements completes in about 25 seconds and updates 4,987,237 rows A CTAS + Partition switch process will look like the following Step 1: Create a copy of the table with the data form the affected partition, in this case partition 79 with a right boundary value of July 1 1998 --create a temp table with matching paritioning --perform transformation here to avoid additional step CREATE TABLE orders_part_switch_temp WITH (CLUSTERED COLUMNSTORE INDEX, DISTRIBUTION = HASH([o_orderkey]), PARTITION ([o_orderdate] RANGE RIGHT FOR VALUES ('Jan 1 1992', 'Feb 1 1992', 'Mar 1 1992', 'Apr 1 1992', 'May 1 1992', 'Jun 1 1992', 'Jul 1 1992', 'Aug 1 1992', 'Sep 1 1992', 'Oct 1 1992', 'Nov 1 1992', 'Dec 1 1992', 'Jan 1 1993', 'Feb 1 1993', 'Mar 1 1993', 'Apr 1 1993', 'May 1 1993', 'Jun 1 1993', 'Jul 1 1993', 'Aug 1 1993', 'Sep 1 1993', 'Oct 1 1993', 'Nov 1 1993', 'Dec 1 1993', 'Jan 1 1994', 'Feb 1 1994', 'Mar 1 1994', 'Apr 1 1994', 'May 1 1994', 'Jun 1 1994', 'Jul 1 1994', 'Aug 1 1994', 'Sep 1 1994', 'Oct 1 1994', 'Nov 1 1994', 'Dec 1 1994', 'Jan 1 1995', 'Feb 1 1995', 'Mar 1 1995', 'Apr 1 1995', 'May 1 1995', 'Jun 1 1995', 'Jul 1 1995', 'Aug 1 1995', 'Sep 1 1995', 'Oct 1 1995', 'Nov 1 1995', 'Dec 1 1995', 'Jan 1 1996', 'Feb 1 1996', 'Mar 1 1996', 'Apr 1 1996', 'May 1 1996', 'Jun 1 1996', 'Jul 1 1996', 'Aug 1 1996', 'Sep 1 1996', 'Oct 1 1996', 'Nov 1 1996', 'Dec 1 1996', 'Jan 1 1997', 'Feb 1 1997', 'Mar 1 1997', 'Apr 1 1997', 'May 1 1997', 'Jun 1 1997', 'Jul 1 1997', 'Aug 1 1997', 'Sep 1 1997', 'Oct 1 1997', 'Nov 1 1997', 'Dec 1 1997', 'Jan 1 1998', 'Feb 1 1998', 'Mar 1 1998', 'Apr 1 1998', 'May 1 1998', 'Jun 1 1998', 'Jul 1 1998', 'Aug 1 1998'))) AS SELECT [o_orderkey] , [o_custkey] , [o_orderstatus] , [o_totalprice] , [o_orderdate] , [o_orderpriority] , [o_clerk] , CASE WHEN o_orderdate BETWEEN '1998-07-24' AND '1998-07-31' THEN 1 ELSE 0 END AS CHAR(15) AS [o_shippriority], [o_comment] FROM dbo.orders_part_switch WHERE o_orderdate BETWEEN '1998-07-01' AND '1998-07-31' This statement writes 19M rows to the stage table. Next we swap our updated partition with the original partition which is a metadata operation and no data is actually moved. ALTER TABLE orders_part_switch_temp SWITCH PARTITION 80 TO orders_part_switch partition 80 WITH (TRUNCATE_TARGET = ON) Then finally drop our stage table DROP TABLE orders_part_switch_temp This batch runs in about 11 seconds, half of the time as the UPDATE statement.
Summary:
Due to CCI overhead and transaction log usage, CTAS w/partition switching may be more performant than using an UPDATE statement. Since the CCI is per partition you also will not decrement the CCI health like an UPDATE statement would. UPDATE Statement: 24 Seconds CTAS & Partition Switch: 12 seconds
Gotchas
The schema needs to be exactly the same between the source and staging table You must utilize partitioning and the updates be limited to one or few partitions. The more partitions that are updated the less advantageous this approach will be. More Info ]]> https://docs.microsoft.com/archive/blogs/apsblog/azure-sql-data-warehouse-sql-operations-studio-extension-available Thu, 07 Jun 2018 21:00:21 GMT https://blogs.msdn.microsoft.com/apsblog/?p=575 integration with SQL Operations Studio. Now they have released a preview of an extension that contains pre built dashboards to monitor you Data Warehouse instances! Today you can monitor data skew, ColumnStore index health, and system resource usage. We expect more scenarios to be added over time so check back! To get started: • Download SQL Operations Studio • Access Extensions Manager and install ‘Azure SQL Data Warehouse Insights’ • Click reload and Connect to SQL DW server. • Right click on server and click ‘Manage.’ Click on DW Tab to see your insights! Be sure to provide your feedback!]]> https://docs.microsoft.com/archive/blogs/apsblog/aps-au7-performance-enhancements Wed, 30 May 2018 19:13:32 GMT https://blogs.msdn.microsoft.com/apsblog/?p=565 ALTER DATABASE commands. Historically the number one root cause for performance issues is inaccurate statistics objects causing the optimizer to make poor cardinality estimations and therefore expensive or even unnecessary data movement operations. We recommend auto create and auto update statistics be enabled for both new and pre-existing databases. If performance is or becomes a concern, the first remediation step should be to enable auto create and auto update statistics on the database, clear the procedure cache and re-run the workload. If there is no benefit realized or in the rare case of performance regression, the statistics objects created can be dropped through T-SQL commands. The second performance enhancement is transparent. In the process of working with many customers after APS 2016 (AU6) deployments, we identified opportunities to streamline our internal process of authorization and plan generation. The gains will be most noticeable on workloads which contain many small queries that run in several seconds or less. Testing has shown performance benefits form minimal to significant depending on the workload and number of statements executed. If your workload includes many short lived queries we recommend upgrading to AU7 to take advantage of the increased efficiencies. ]]> https://docs.microsoft.com/archive/blogs/apsblog/set-implicit_transactions-behavior-on-azure-sql-data-warehouse-and-aps Tue, 20 Feb 2018 20:11:41 GMT https://blogs.msdn.microsoft.com/apsblog/?p=505 Before we begin . . . Let's first consider the following sample Java program: [java]import java.sql.*; public class TrxTest { public static void main(String[] args) { // Create a variable for the connection string. //String connectionUrl = "jdbc:sqlserver://localhost;instanceName=SQL2016;databaseName=SmpHotnessDB;user=SmpUser;password=*****"; String connectionUrl = "jdbc:sqlserver://MppHotnessServer.database.windows.net;databaseName=MppHotnessDB;user=MppUser;password=*****"; // Declare the JDBC objects. Connection connection = null; Statement statement = null; ResultSet rs = null; try { // Establish the connection. Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver"); connection = DriverManager.getConnection(connectionUrl); statement = connection.createStatement(); statement.execute("CREATE TABLE dbo.transaction_001 (id INT)"); statement.execute("INSERT INTO dbo.transaction_001 (id) VALUES (1)"); // Try one transaction // BEGIN TRANSACTION connection.setAutoCommit(false); statement.execute("DELETE FROM dbo.transaction_001 WHERE id = 1"); statement.execute("INSERT INTO dbo.transaction_001 (id) VALUES (10)"); connection.commit(); connection.setAutoCommit(true); // END TRANSACTION // Following statement fails with "Operation cannot be performed within a transaction" statement.execute("CREATE TABLE dbo.transaction_001_new (id INT)"); } // Handle any errors that may have occurred. catch (Exception e) { e.printStackTrace(); } finally { if (statement != null) try { statement.close(); } catch(Exception e) {} if (connection != null) try { connection.close(); } catch(Exception e) {} } } }[/java] Assuming you have both an SMP instance and an MPP (ADW/APS) instance handy, you can run the above and switch between the two platforms to test the differences. When running against an SMP instance, everything works as one would expect. However, when executing against ADW/APS, you receive the following error:

What's Happenin'

The error you receive from ADW/APS is due to an enforced restriction on these platforms. You are likely familiar with (and perhaps frustrated by) the fact that DDL operations can't be wrapped in a transaction. Regardless, this error is admittedly confusing because the setAutoCommit(true) method should have committed any open transactions, leaving the open transaction count at 0. Though SMP cleans up when the connection.setAutoCommit(true) statement is issued, ADW/APS doesn't (exactly). In short, this is because ADW/APS will immediately open a transaction following a SET IMPLICIT_TRANSACTIONS ON statement; more than this, ADW/APS will start a new transaction even after a COMMIT TRAN is issued when IMPLICIT_TRANSACTIONS is ON. As such, ADW/APS perpetually maintains a transaction count of (at least) 1 while IMPLICIT_TRANSACTIONS is ON. To contrast, SMP won't issue a new transaction until a new DML or DDL statement is issued after the COMMIT TRAN statement. You can test this behavior by issuing the following statements (which are effectively what the Java program sends to the database with some insert SELECT @@TRANCOUNT statements) one at a time against each different platform: [sql]SELECT @@TRANCOUNT CREATE TABLE dbo.transaction_001 (id INT) INSERT INTO dbo.transaction_001 (id) VALUES (1) SELECT @@TRANCOUNT set implicit_transactions on; SELECT @@TRANCOUNT DELETE FROM dbo.transaction_001 WHERE id = 1 INSERT INTO dbo.transaction_001 (id) VALUES (10) SELECT @@TRANCOUNT IF @@TRANCOUNT > 0 COMMIT TRAN SELECT @@TRANCOUNT IF @@TRANCOUNT > 0 COMMIT TRAN SELECT @@TRANCOUNT set implicit_transactions off SELECT @@TRANCOUNT CREATE TABLE dbo.transaction_001_new (id INT) SELECT @@TRANCOUNT [/sql]

Make It Right

This difference in behavior complicates existing coding patterns against SQL Server SMP when applied to ADW/APS because a manual COMMIT TRAN must be issued in order to properly close out a transaction even after setAutoCommit(true) is executed: [java] // BEGIN TRANSACTION connection.setAutoCommit(false); statement.execute("DELETE FROM dbo.transaction_001 WHERE id = 1"); statement.execute("INSERT INTO dbo.transaction_001 (id) VALUES (10)"); connection.commit(); connection.setAutoCommit(true); statement.execute("if @@trancount > 0 commit tran"); // END TRANSACTION [/java] When this is in place, IMPLICIT_TRANSACTIONS is OFF and all open transactions have been properly closed.

Before We're done - IMHO . . .

One could argue that the behavior of setAutoCommit(true) could be improved to issue the following: [sql]IF @@TRANCOUNT > 0 COMMIT TRAN set implicit_transactions off IF @@TRANCOUNT > 0 COMMIT TRAN [/sql] Instead of: [sql]IF @@TRANCOUNT > 0 COMMIT TRAN IF @@TRANCOUNT > 0 COMMIT TRAN set implicit_transactions off [/sql] Alas, it doesn't . . . so you have to account for this. And this is the point: you can't necessarily always control how a given package/library/API implements its transaction control with a database; such is the case in the above scenario. However, you can better control transactions in ADW/APS if you:
1. Leave IMPLICIT_TRANSACTIONS = OFF (aka, setAutoCommit(true)) and
2. Utilize stored procedures to manage transactions rather than do it from another language's implementation

Helpful Links

https://docs.microsoft.com/en-us/sql/connect/jdbc/reference/setautocommit-method-sqlserverconnection https://docs.microsoft.com/en-us/sql/t-sql/statements/set-implicit-transactions-transact-sql https://docs.microsoft.com/en-us/sql/connect/jdbc/building-the-connection-url Thanks to my technical reviewers: Allan Miller & Charl Roux]]> https://docs.microsoft.com/archive/blogs/apsblog/azure-resource-manager-arm-and-azure-sql-data-warehouse Wed, 14 Feb 2018 03:36:09 GMT https://blogs.msdn.microsoft.com/apsblog/?p=485 { "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "serverName": { "type": "string", "minLength": 1 }, "serverAdminLogin": { "type": "string", "minLength": 1 }, "serverAdminLoginPassword": { "type": "securestring" }, "databaseName": { "type": "string", "minLength": 1 }, "databaseCollation": { "type": "string", "minLength": 1, "defaultValue": "SQL_Latin1_General_CP1_CI_AS" }, "databaseEdition": { "type": "string", "defaultValue": "DataWarehouse", "allowedValues": [ "DataWarehouse" ] }, "RequestedServiceObjectiveName": { "type": "string", "defaultValue": "DW100", "allowedValues": [ "DW100" ], "metadata": { "description": "Describes the performance level for Edition" } } }, "variables": { "dwserverName": "[concat(parameters('serverName'), uniqueString(resourceGroup().id))]" }, "resources": [ { "name": "[variables('dwserverName')]", "type": "Microsoft.Sql/servers", "location": "[resourceGroup().location]", "apiVersion": "2014-04-01-preview", "dependsOn": [ ], "properties": { "administratorLogin": "[parameters('serverAdminLogin')]", "administratorLoginPassword": "[parameters('serverAdminLoginPassword')]" }, "resources": [ { "name": "AllowAllWindowsAzureIps", "type": "firewallrules", "location": "[resourceGroup().location]", "apiVersion": "2014-04-01-preview", "dependsOn": [ "[resourceId('Microsoft.Sql/servers', variables('dwserverName'))]" ], "properties": { "startIpAddress": "0.0.0.0", "endIpAddress": "0.0.0.0" } }, { "name": "[parameters('databaseName')]", "type": "databases", "location": "[resourceGroup().location]", "apiVersion": "2014-04-01-preview", "dependsOn": [ "[resourceId('Microsoft.Sql/servers', variables('dwserverName'))]" ], "properties": { "collation": "[parameters('databaseCollation')]", "edition": "[parameters('databaseEdition')]", "requestedServiceObjectiveName": "[parameters('RequestedServiceObjectiveName')]" } } ] }], "outputs": {} } Editing a Template I have to recommend you either use Visual Studio Code or Visual Studio 2017. You can install Azure Resource Manager Tools in VSCode while Visual Studio with Azure Tools installed has the Azure Resource Group project type with a JSON Outline that helps when editing the template. When modifying the template, it is important to know the Microsoft.Sql/Servers settings and the database settings. The audit settings that can be specified with an Azure SQL DB are not supported on Azure SQL Data Warehouse. The settings are not supported because they are for Blob auditing and at the time of this writing, the Azure SQL Data Warehouse only supports table auditing. The template will almost always be accompanied with a parameters JSON file that will store the standard values for your deployment. If you have more than one environment, you can have more than one parameter file and specify which one you want depending on where you are deploying. An easy way to think about this is Development, Test, and Production will each have a different parameters file that would detail the server, Resource Group and Data Warehouse for that environment. Below is an example parameter file.   { "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "databaseCollation": { "value": "SQL_Latin1_General_CP1_CI_AS" }, "databaseEdition": { "value": "DataWarehouse" }, "databaseName": { "value": "dwarmtestdb" }, "RequestedServiceObjectiveName": { "value": "DW100" }, "serverAdminLogin": { "value": "dwadmin" } } }     Troubleshooting Your Template Deployment When things go wrong with your template deployment, it can be a very unsettling experience. If you used PowerShell New-AzureRMResourceGroupDeployment as your deployment method, the error is provided as part of the result. One of the best things I have found to help in working with the templates is in the Azure Portal by navigating to the Resource Group in question and looking at the Deployments blade. In the Deployments blade, you can see the successful and failed deployments with details as with the screenshot below. You can see that using deploying a Data Warehouse, the max size property does not appear to be supported or will need match a MAXSIZE of the CREATE DATABASE statement, though I was not able to get it to work with any values. I recommend if you need to create an Azure SQL Data Warehouse of a specific size, use the CREATE DATABASE statement. Have fun deploying!]]> https://docs.microsoft.com/archive/blogs/apsblog/performance-evaluate-data-skew Fri, 19 Jan 2018 23:49:10 GMT https://blogs.msdn.microsoft.com/apsblog/?p=475 DBCC PDW_SHOWSPACEUSED ( " [ database_name . [ schema_name ] . ] | [ schema_name .] table_name  " )   to get the row count per distribution, it will not give you insight into the density of the data.  If you want to see the actual values the data is skewed on, you can run the following query against the instance:   SELECT Count([distribution_column]) AS [Row Count], [distribution_column] FROM [table_name] group by [distribution_column] ORDER BY [Row Count] DESC   If there is a large disparity in the row counts for a couple of values, the distributions those land on will have skew. You will have to decide if this skew is acceptable for your application. In general we say 20% is acceptable. ]]> https://docs.microsoft.com/archive/blogs/apsblog/how-to-move-your-azure-data-warehouse-to-a-new-region-andor-subscription Thu, 14 Dec 2017 01:15:41 GMT https://blogs.msdn.microsoft.com/apsblog/?p=445 Azure SQL Data Warehouse The functionality currently does not exist to move your Azure SQL Data Warehouse instance to a subscription other than the one it was created under.  What you can do is move the server that contains the instance to another subscription or resource group.  Moving a server will move all SQL Databases owned by that server to the destination subscription.  The only limitation is both subscriptions must exist within the same Active Directory Tenant.  The link below stats how to determine what tenant a resource belongs to.   The process will be slightly different depending on if you are simply moving an existing DW instance to a different subscription or if you wish to create a copy or if you wish to move across regions. Process
1. To move an existing server and Data Warehouse to a new subscription without changing region simply follow the instructions here
2. To create a copy of an existing Data Warehouse or Move the Data Warehouse to a new region you will need to add in a geo-restore of the instance
   1. Restore the Data Warehouse to a new server in the same subscription in the desired region
   2. Move the new server owning the Data Warehouse to the desired subscription
  If you have any issues with this approach feel free to contact us @ support any time!  ]]> https://docs.microsoft.com/archive/blogs/apsblog/pdw-performance-investigate-inconsistent-query-execution-times Thu, 22 Jun 2017 18:16:11 GMT https://blogs.msdn.microsoft.com/apsblog/?p=365 this post. If the two executions had similar wait times for concurrency and object locks, next you need to drill into the execution of the query. Compare the overall execution for different runs of the same query: SELECT fast.step_index, fast.operation_type, fast.total_elapsed_time                           AS fast_total, slow.total_elapsed_time                           AS slow_total, slow.total_elapsed_time - fast.total_elapsed_time AS time_delta, fast.row_count                                    AS fast_row_count, slow.row_count                                    AS slow_row_count, slow.row_count - fast.row_count                   AS row_count_delta FROM   (SELECT * FROM   sys.dm_pdw_request_steps WHERE  request_id = '<fast_request_id>') fast INNER JOIN (SELECT * FROM   sys.dm_pdw_request_steps WHERE  request_id = '<slow_request_id>') slow ON fast.step_index = slow.step_index ORDER  BY step_index ASC     The operation list should be identical between two identical queries.  Pick the operation with the most variance and compare between two request_ids.  Depending on the type of operation will determine which DMV will have the appropriate data:  Data movement step:   SELECT fast.pdw_node_id, fast.distribution_id, fast.type, fast.total_elapsed_time                           AS fast_time_total, slow.total_elapsed_time                           AS slow__time_total, slow.total_elapsed_time - fast.total_elapsed_time AS time_delta, slow.rows_processed - fast.rows_processed         AS row_count_delta, slow.cpu_time - fast.cpu_time                     AS CPU_time_delta, slow.query_time - fast.query_time                 AS query_time_delta, slow.bytes_processed - fast.bytes_processed       AS bytes_processed_delta FROM   (SELECT * FROM   sys.dm_pdw_dms_workers WHERE  request_id = '<fast query id>' AND step_index = <step index>) FAST INNER JOIN (SELECT * FROM   sys.dm_pdw_dms_workers WHERE  request_id = '<slow query id>' AND step_index = <step_index>) SLOW ON FAST.pdw_node_id = slow.pdw_node_id AND fast.distribution_id = slow.distribution_id AND fast.type = slow.type      Other operation: SELECT fast.step_index, fast.pdw_node_id, fast.distribution_id, fast.total_elapsed_time                           AS fast_time, slow.total_elapsed_time                           AS slow_time, slow.total_elapsed_time - fast.total_elapsed_time AS time_delta FROM   (SELECT * FROM   sys.dm_pdw_sql_requests WHERE  request_id = '<fast query id>') fast INNER JOIN (SELECT * FROM   sys.dm_pdw_sql_requests WHERE  request_id = '<slow query id>') slow ON fast.distribution_id = slow.distribution_id       Pay attention to start and end times for each distribution as well as rows and bytes processed to look for any discrepancies.  Concurrency can significantly impact performance by creating a bottleneck on a system resource but will not be evident in these results.  It is always best to baseline a query with no concurrent executions if possible.      The goal of this article is not to identify a specific reason query execution times vary, but rather how to access the data detailing the execution and identify areas which require further investigation.  Once an anomaly is identified, further investigation may be needed.  ]]>