This post has been republished via RSS; it originally appeared at: Azure Database Support Blog articles.
First published on MSDN on Nov 02, 2018I recently had a client approach me on an error that they persistently encountered when attempting to start an extended event session in the Azure SQL Database service. The SqlException error message consisted of the following:
Msg 25602, Level 16, State 1, Line 178
The target, "0DCF1903-7977-40A7-B7A8-339AA9D8D7F0.package0.event_file", encountered a configuration error during initialization. Object cannot be added to the event session. The operating system returned error 13: 'The data is invalid.' while creating the file 'https://<storage account>.blob.core.windows.net/<container>/eevent_3_0_131856532944580000.xel'.
The error message tells us that there was a problem encountered when attempting to write to the blob container specified. We reviewed the associated storage account’s configuration to verify that SQL Database had permission to perform read , write , and list operations; and re-created the DATABASE SCOPED CREDENTIAL defined to ensure the SECRET value was the full Shared Access Signature query string (minus the character, ‘?’, of course). We also confirmed that extended event sessions had targeted the correct storage account container endpoint. Still, despite the aforementioned, the issue had persist.
Curious about this, the client was asked to identify the storage account type being used. The client confirmed that they were using the blob storage account type . When attempting to use a general-purpose v2 account type , however, the issue does not occur. I then reviewed Azure storage documentation at https://docs.microsoft.com/en-us/azure/storage/common/storage-account-overview#types-of-storage-accounts to compare the differences between the storage account types we offer. It turns out, the blob storage account type only supports block and append blobs; page blobs are not supported. Extended events are written as page blobs, as they are written to storage as random-accessible pages. This was why an error occurred when attempting to write extended event data to an Azure blob storage account type .
Unfortunately, “ Azure storage ,” and, “ blob storage ,” are referenced interchangeably as service concepts throughout many of our documents, which can inadvertently give the illusion that, “ blob storage ,” supports all blob types ( block , append , and page ) when, in reality, the blob storage account type specifically does not. I thus wanted to take a moment to share this experience in case someone should run into this scenario in the future. As for a solution to the matter, options are limited to upgrading the blob storage account type to a general-purpose v2 ; or, to use another storage account that is of type general-purpose (v2 preferably, since v2 uses Azure Resource Manager). Instructions on the former can be found here: https://docs.microsoft.com/en-us/azure/storage/common/storage-account-upgrade .
If anyone is looking for direction on how to set up extended events with general-purpose storage account types, please refer to my colleague’s blog at https://blogs.msdn.microsoft.com/azuresqldbsupport/2018/03/13/extended-events-capture-step-by-step-walkthgrough/ .