In-Memory OLTP Update

In November 2016, we announced the general availability (GA) of In-Memory OLTP technology in Azure SQL Database worldwide. From then on we have been working towards unlocking some more useful features which we believe will significantly help you leverage this technology more efficiently into your applications.

Today we are pleased to announce a string of improvements to In-Memory OLTP technology in Azure SQL Database, which spans multiple avenues and continues to unlock and expand the T-SQL surface area and improve the overall manageability.

The new feature improvements are listed below and are available today in Azure SQL Database and will also be available in SQL Server vNext.  

Increased number of indexes for memory-optimized tables

The limitation of 8 indexes for memory-optimized tables has been eliminated. You can now create as many indexes on memory-optimized tables as you can create on disk-based tables.

Any disk-based table in your database that you could not migrate previously because of this limitation can now be memory-optimized, and thus leverage the performance benefits of In-Memory OLTP technology.  

In-Memory OLTP schema management

The GA of In-Memory OLTP in Azure SQL Database included support for ALTER operations on memory-optimized objects. This enabled you to perform most schema management operations such as adding or dropping columns, managing indexes, and updating natively compiled stored procedures. At that time, the one operation not yet supported was renaming objects.

We have addressed this now by adding support for the system stored procedure sp_rename with memory-optimized tables and natively compiled T-SQL modules. With this, Azure SQL Database now supports all the main schema management operations for In-Memory OLTP.

sp_rename – sp_rename is used to change the name of the user object in the current database. In-Memory OLTP objects such as tables, table columns, natively compiled procedures, etc. can now all be renamed with this stored procedure.

Note that natively compiled T-SQL modules must be created as schema-bound modules. Tables, columns, and modules referenced from a schema-bound module cannot be renamed. Therefore, to rename a table or column referenced from a natively compiled T-SQL module, first drop the module, then perform the rename, and finally recreate the module referencing the new name.

Max commit dependencies limit eliminated

The limit on the maximum number of transactions a given transaction depends on or the number of transactions that depend on a given transaction is eliminated. 

So you will no longer receive the corresponding error message: "41839: Transaction exceeded the maximum number of commit dependencies".

Extended T-SQL support for In-Memory OLTP

In-Memory OLTP in Azure SQL Database at GA supported T-SQL surface area that was on full parity with SQL Server 2016, including support for constructs like DISTINCT, SUBQUERIES, IN, EXISTS, OR, NOT, OUTER JOIN, etc.

We have further extended the T-SQL support and added the following:

CASE – CASE expressions are now fully supported in SELECT statements in natively compiled T-SQL modules. Prior to this you would have to create a table variable to construct the single result set and from this table variable you would then SELECT based on the predicate that defines the CASE.
COMPUTED COLUMNS – Computed columns, as well as indexes on computed columns, are now supported in memory-optimized tables. Additionally, you can now also create indexes on these computed columns in memory-optimized tables.
CROSS APPLY and JSON – The CROSS APPLY operator is now supported in natively compiled T-SQL modules. In addition, all JSON functions and clauses are now supported in natively compiled T-SQL modules and on constraints in memory-optimized tables. Indexes on computed columns allow indexing JSON data. Learn more about optimizing JSON processing using In-Memory OLTP.

Another feature worth mentioning is the support for sp_spaceused. Even though on Azure SQL Database the storage is managed for you by the platform, sp_spaceused will give you a good insight into the storage characteristics of the data stored in memory-optimized tables.

sp_spaceused – sp_spaceused can now be used to understand the storage footprint associated with In-Memory OLTP. A new parameter '@include_total_xtp_storage' has been added to the stored procedure for the same. Get more details about sp_spaceused​.

If you are currently leveraging In-Memory OLTP technology in your application or if you do plan on using it in the future, we sincerely hope that these improvements will enable new scenarios for you whilemaking it easier for you to leverage this technology in your application.
Quelle: Azure

Application Insights support for Microservices and Containers

We’ve recently made it much easier to monitor microservices and containerized applications using Azure Application Insights. A single Application Insights resource can be used for all the components of your application. The health of the services and the relationships between them are displayed on a single Application Map. You can trace individual operations through multiple services with automatic HTTP correlation. Metrics from Docker, and other containers, can be integrated and correlated with application telemetry. Segmenting Application Insights data by role Until now, Application Insights has assumed that you create one Application Insights resource, and instrumentation key, for each server component or microservice in your application. With a microservices application, a single application can be composed of many different services, and it can be very time consuming to create and maintain separate resources. It’s also difficult to correlate results between them. To solve this problem, we have added the capability for you to segment data in Application Insights by the cloud_RoleName property that is attached to all telemetry. This allows you to send all the data from all your servers to a single Application Insights resource, and filter on cloud_RoleName to see performance and health information for individual microservices. The cloud_RoleName property is set by SDKs to represent the appropriate name for your microservice, container, or app name in Azure App Service. In the Failures, Performance, and metrics explorer blades, you will see new Cloud role name properties in the filter menu: In the above example, we filtered the failures blade to show just the information for our front-end web service, filtering out failures from the CRM API backend. We’ve also enabled a preview feature that allows the Application Map to segment server nodes by cloud_RoleName. To enable this capability, set Multi-role Application Map to On from the Previews blade. After enabling this preview, your map will show one server node for each unique value set in the cloud_RoleName field:   The calls between servers are tracked by using correlation Ids passed in the headers of HTTP requests, which we’ll talk about next. Automatic HTTP correlation that works in containers With the latest SDKs, 2.4.0-beta3 for ASP.NET and 2.1.0-beta3 for ASP.NET Core, we automatically correlate calls between services by injecting headers into the HTTP requests and responses. Previously this functionality required installing an instrumenting profiler, using the Application Insights Site Extension for App Services, or installing Status Monitor for other Azure Compute services. These extensions are difficult to provision in Service Fabric or Docker container environments. This allows you to see all your microservices and containerized applications on the application map. You can also see all the telemetry related to cross-server calls in a single view. For example, here is an exception from our visitors app sample: Click through to a correlated list of telemetry for this operation across the front-end web server and the back-end API: To take advantage of this capability, install the current pre-release versions of Application Insights SDKs available on NuGet. SDK Support for .NET Core 2.0, Service Fabric, and Kubernetes We have made improvements to our .NET SDKs so that the above features will work for .NET applications running in Service Fabric and Kubernetes. Our ASP.NET Core 2.1 SDK now supports both .NET Core 1.1 and .NET Core 2.0 Preview 1, including automatic request and dependency tracking capabilities. This allows you to get the full Application Insights experience with the latest versions of .NET Core. If your application runs on Service Fabric, you can use our Service Fabric SDKs for Application Insights. Add the Microsoft.ApplicationInsights.ServiceFabric.Native NuGet package for Service Fabric reliable services and the Microsoft.ApplicationInsights.ServiceFabric package for guest executables and Docker containers. Many Service Fabric applications use EventSource for high-scale logging. You can now log EventSource events to Application Insights by adding the Microsoft.ApplicationInsights.EventSourceListener package. If your application runs in Docker on Kubernetes, you can use our Kubernetes SDK by adding the Microsoft.ApplicationInsights.Kubernetes package to your app. Use NuGet package manager in Visual Studio to add the packages mentioned in this section. Check the “include previews” option to find the packages mentioned in this section. Container metrics for Windows Docker Containers It’s useful to see CPU, Memory, and other metrics about your individual Docker containers so that you can understand the health of your containers and achieve the right density of containers on physical machines. We have enriched our Windows Azure Diagnostics Extension (WAD) with support for collecting metrics from Docker containers running on Windows. Once you have WAD installed, you can simply modify your diagnostics configuration file to collect Docker stats and send them to Application Insights. Try it out today We hope these new capabilities will allow you to have a great experience using Application Insights with microservices and containerized applications. Be sure to check out the docs, try out the SDKs and let us know how we can make Application Insights work better for you in these new environments. In addition to the capabilities listed in this post, we’ve recently announced many other improvements to Application Insights that will help you find and fix issues in your applications. As always, please share your ideas for new or improved features on the Application Insights UserVoice page. For any questions visit the Application Insights Forum.
Quelle: Azure