SQL Archives - CodeJourney.net

How To Fix SqlException Database Is Not Currently Available On Azure (0x80131904)

Dawid Sibiński — Tue, 17 May 2022 05:32:15 +0000

I recently deployed my .NET 6 application to Microsoft Azure. The app uses NHibernate for working with SQL Server database. After some time, I started getting an unhandled exception when opening the application:

NHibernate.Exceptions.GenericADOException: could not load an entity: 
...
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-9042-2B83EEE57B91}'.

The database is not currently available was very interesting to me. I struggled a bit with solving that, so if you want to know how I did it – continue reading

The problem

My .NET 6 app is an Azure App Service, and it uses SQL Server database. Quite standard Azure stuff.

The issue was that when opening the ASP.NET web app after some time of inactivity, there was an HTTP 500 error. When I checked the logs, the full error looked as follows:

NHibernate.Exceptions.GenericADOException: could not load an entity: [MyApp.Infrastructure.DomainObjects.ApplicationUser#37931c5a376748d7a49f215ca30283a2][SQL: SELECT applicatio0_.applicationuser_key as id1_3_0_, applicatio0_1_.UserName as username2_3_0_, applicatio0_1_.NormalizedUserName as normalizedusername3_3_0_, applicatio0_1_.Email as email4_3_0_, applicatio0_1_.NormalizedEmail as normalizedemail5_3_0_, applicatio0_1_.EmailConfirmed as emailconfirmed6_3_0_, applicatio0_1_.PhoneNumber as phonenumber7_3_0_, applicatio0_1_.PhoneNumberConfirmed as phonenumberconfirmed8_3_0_, applicatio0_1_.LockoutEnabled as lockoutenabled9_3_0_, applicatio0_1_.LockoutEnd as lockoutend10_3_0_, applicatio0_1_.AccessFailedCount as accessfailedcount11_3_0_, applicatio0_1_.ConcurrencyStamp as concurrencystamp12_3_0_, applicatio0_1_.PasswordHash as passwordhash13_3_0_, applicatio0_1_.TwoFactorEnabled as twofactorenabled14_3_0_, applicatio0_1_.SecurityStamp as securitystamp15_3_0_ FROM ApplicationUsers applicatio0_ inner join dbo.AspNetUsers applicatio0_1_ on applicatio0_.applicationuser_key=applicatio0_1_.Id WHERE applicatio0_.applicationuser_key=?]
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-2342-2B836E35E891}'.
   at Microsoft.Data.ProviderBase.DbConnectionPool.CheckPoolBlockingPeriod(Exception e)

There were two characteristics of this error:

it always appeared after some time of not using the web app
I never reproduced it locally

So it must have been something wrong with Azure.

Transient issues in Azure databases

First thing I did, obviously, was checking Azure App Service logs. This is what I found:

The first recommended step got me curious. To reduce the impact of connection issues caused by future reconfiguration, please implement retry logic in your code.

So I started reading. There’s even official Microsoft documentation for that. It basically says that in the cloud environment you’ll find that failed and dropped database connections happen periodically.

I must admit it seemed quite new to me. However, I started digging into that. I used Polly to implement the retry logic in my app. I found few places where there was an NHibernate query for fetching users executed and wrapped it into the retry policy.

Nothing worked. I was still getting the error. Then, after some talks with my coworkers, we found the real reason behind that…

Solution: Azure database tier

When talking about the issue with my teammates, someone mentioned that the databases in Azure are serverless by default.

I logged into the Azure Portal and checked the “Compute + storage” settings my SQL database my app used:

Indeed, the tier selected was “General purpose (Scalable compute and storage options)” with “Serverless” compute tier selected.

I changed it to “Basic (For less demanding workloads)”:

and… it worked All errors saying that the database is not currently available disappeared. I also removed all Polly-related code for retry policies.

A little explanation

Why do serverless databases in Azure behave like that?

I finally found this explanation in the Microsoft documentation:

If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. Once the database is resumed, the login must be retried to establish connectivity

That blew my mind! It means that the database is not currently available exception is expected. There’s also another part there:

Database clients with connection retry logic should not need to be modified. For connection retry logic options that are built-in to the SqlClient driver, see configurable retry logic in SqlClient.

Apparently, users of ORMs like Entity Framework should not have to worry about those issues. Unfortunately, NHibernate doesn’t have such built-in transient errors retry logic. That’s why I experienced this particular issue and couldn’t find any straightforward solution online. Simply not many people (if anyone at all? ) experienced this before.

If you want even more details and context, check out this article: SHOULD I USE SERVERLESS FOR ALL MY AZURE SQL DATABASES?

What if I want to use serverless Azure database?

Well… if you really want to use the serverless features of Azure, you might be struggling with NHibernate. As I mentioned, apparently there’s no built-in transient failures retry mechanism in the ORM. There’s one promising solution here. However, currently it’s build for NHibernate 3.3.1.4000, so it doesn’t work with the current version. There’s a Pull Request and an issue opened for upgrading it to the newest version and .NET 6/7. Let’s hope it is done soon.

Otherwise, you can try using Polly as I did initially. However, I didn’t manage to make fully working.

If you have any other idea or solution – let us know in the comments below.

Conclusion

I hope this article saves you some hours of debugging, so you can quickly solve this database is not currently available error in Azure. I wish I found this article on another website few weeks ago

The post How To Fix SqlException Database Is Not Currently Available On Azure (0x80131904) appeared first on CodeJourney.net.

T-SQL/SSMS: transaction rollback in scripts with XACT_ABORT ON, GO statements and syntax errors

Dawid Sibiński — Thu, 16 Nov 2017 07:00:40 +0000

I’ve recently met a weird issue with T-SQL scripts at work and would like to share it with you today

T-SQL script with multiple objects created

On daily basis I work a lot with MS SQL Server databases. We often create many T-SQL objects (tables, views, procedures, functions) and because of some reasons we cannot use Entity Framework or another from widely available ORMs. Nonetheless, all objects created in the database must be kept in the form of SQL scripts (files) containing set of CREATE, ALTER, INSERT, DELETE or whatever T-SQL statements.

What we often do is to create a single .sql file, which in fact often contains more than one, separate (independent) SQL statements (e.g. creates a table and a procedure). What we obviously want to ensure is that when executing the script either all statements are committed to the database or none of them. This means that if in a part responsible for creating a particular object any SQL error is raised, execution of the whole script should be interrupted and the whole transaction rolled back, so in effect none of the objects contained within this script are created (none of the statements batches is committed). Here the issue comes out.

SQL script with XACT_ABORT ON and GO statements

In order to handle above-described requirements, the template for SQL script looks as follows:

	SET XACT_ABORT ON
	GO
	BEGIN TRANSACTION
	GO

	— SQL object 1 (CREATE/ALTER/INSERT etc…)
	GO

	— SQL object 2 (CREATE/ALTER/INSERT etc…)
	GO

	— next SQL batches if needed, each followed by GO

	COMMIT
	GO

view raw

SQL_template.sql

hosted with ❤ by GitHub

Firstly, we set XACT_ABORT to ON. This setting, according to Microsoft docs, “specifies whether SQL Server automatically rolls back the current transaction when a Transact-SQL statement raises a run-time error”. That’s what we want – in case of any errors the whole opened transaction should be rolled back.

Then we open a transaction with BEGIN TRANSACTION, which is committed to the server at the end of the script with COMMIT statement.

In between, we put the actual SQL statements that are responsible for creating new SQL objects or sometimes executing some procedure, inserting some data etc.

As can be noticed, each of these SQL “chunks” is followed by a GO statement. GO is one of the SQL Server statements, that are not T-SQL statements, but are recognized by the sqlcmd utility and SQL Server Management Studio (SSMS). GO statement allows to separate a script into batches. When GO is used, it signals the end of a batch and sends it to the SQL Server. It is necessary in order to separate T-SQL statements (e.g. to separate a procedure’s creation part from another procedure’s EXEC statement coming just after). That is also what comes in default in scripts generated by SSMS.

Of course, everything is in one, big transaction, so everything will be ok, right? When there is any error in any of the batches all other statements will be rolled back? Not necessarily!

XACT_ABORT ON and syntax errors

If we take a closer look at the above-cited description of XACT_ABORT from the Microsoft docs, it says that with this setting set to ON, transaction is rolled back “when a Transact-SQL statement raises a run-time error“. Bold part is crucial here – it only works for run-time errors.

Let’s consider the following sample .sql script:

	SET xact_abort ON
	GO

	BEGIN TRANSACTION
	GO

	CREATE TABLE [dbo].[People]
	(
	[id] [INT] IDENTITY(1, 1) NOT NULL,
	[name] [NVARCHAR](max) NOT NULL,
	[timestamp] [TIMESTAMP] NOT NULL,
	CONSTRAINT [PK_People] PRIMARY KEY CLUSTERED ( [id] ASC )WITH (pad_index =
	OFF, statistics_norecompute = OFF, ignore_dup_key = OFF, allow_row_locks =
	on, allow_page_locks = on) ON [PRIMARY]
	)
	ON [PRIMARY]
	textimage_on [PRIMARY]
	GO

	CREATE PROCEDURE [dbo].[InsertPerson] @name NVARCHAR(max)
	AS
	BEGIN
	INSERT INTO dbo.People
	(NAME)
	VALUES (@name);
	END
	GO

	INSERT INTO dbo.Persons — run-time error – dbo.Persons table does not exist
	(NAME)
	VALUES ('Dawid')
	GO

	COMMIT
	GO

view raw

PeopleTable_proc_exec.sql

hosted with ❤ by GitHub

Here we have 3 T-SQL batches:

Lines 7-17 contain a table’s creation statement
Lines 20-26 contain a procedure’s creation statement
Lines 29-31 contains an INSERT statement.

The last batch contains run-time error – there is no table dbo.Persons in the db. Execution of the above script in SSMS returns the following error:

	Msg 208, Level 16, State 1, Line 33
	Invalid object name 'dbo.Persons'.
	Msg 3902, Level 16, State 1, Line 39
	The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.

view raw

TSQL_runtime_error.log

hosted with ❤ by GitHub

What we expect to happen is that because the last batch produced run-time error, the table and the procedure will not be created. And exactly this happens – neither the table nor the procedure is created in the database. SET XACT_ABORT ON did its job. Uff.

Now, let’s modify the last, INSERT statement by introducing a syntax error so it looks as follows:

	INssSERT INTO dbo.Persons — syntax error – 'INssSERT' instead of 'INSERT'
	(NAME)
	VALUES ('Dawid')

view raw

Insert_with_syntax_error.sql

hosted with ❤ by GitHub

Full .sql script with this change is available here.

Does it change a lot? We will still get an error during the script’s execution, right? Yes – we will get the following error:

	Msg 156, Level 15, State 1, Line 29
	Incorrect syntax near the keyword 'INTO'.

view raw

TSQL_syntax_error.log

hosted with ❤ by GitHub

However, surprisingly, the table and the procedure are well-created in the database! The following screenshot presents:

Objects created despite an error

Why did it happen? Why XACT_ABORT set to ON the whole transaction was not rolled back? That’s because, after re-reading again-mentioned Microsoft docs, “compile errors, such as syntax errors, are not affected by SET XACT_ABORT“. Huh!

Solution

The only solution to this issue I found so far is to check, after each GO statement, if any errors occurred (using @@error) and if yes, interrupt the whole script’s execution using raiserror, for instance:

	INssSERT INTO dbo.Persons (NAME) VALUES ('Dawid')
	GO
	if @@error != 0 raiserror('Error in script execution', 20, -1) with log
	GO

view raw

GO_raiserrror_usage.sql

hosted with ❤ by GitHub

After introducing this solution to our example script, it looks as in this gist. After executing it in SSMS, the error is a bit different:

	Msg 156, Level 15, State 1, Line 33
	Incorrect syntax near the keyword 'INTO'.
	Msg 2745, Level 16, State 2, Line 37
	Process ID 53 has raised user error 50000, severity 20. SQL Server is terminating this process.
	Msg 50000, Level 20, State 1, Line 37
	Error in script execution
	Msg 596, Level 21, State 1, Line 36
	Cannot continue the execution because the session is in the kill state.
	Msg 0, Level 20, State 0, Line 36
	A severe error occurred on the current command. The results, if any, should be discarded.

view raw

TSQL_raiseerror.log

hosted with ❤ by GitHub

and neither the table nor the procedure is created in the database. That’s what we need.

Summary

I found this issue confusing and weird, especially that I could not find any equivalent to XACT_ABORT which would satisfy my needs and affect also syntax errors. The solution with checking for errors after each GO statement works fine, but is far from perfect.

Maybe you have some more experience in this topic and know any better solution? It’d be appreciated!

The post T-SQL/SSMS: transaction rollback in scripts with XACT_ABORT ON, GO statements and syntax errors appeared first on CodeJourney.net.