This post is similar to another question listed here. Encrypting data by OPEN SYMMETRIC KEY by ASYMMETRIC KEY created with Azure provider in SQL server takes more than 2 min

We are also facing the similar problem on our PROD server randomly, did anyone find a fix for this one. Below is the SQL statement we are executing with timestamp, randomly the time taken between the statement print 'before open ....' and print 'after open ....' is more than a minute and at a time is less than a second.

print 'before open ' + convert(varchar(50),getdate(),114)


print 'after open ' + convert(varchar(50),getdate(),114)

-- SQL Select query


print 'after close ' + convert(varchar(50),getdate())

enter image description here

Few findings from our end.

There is no error reported, just a continous info logged in eventviewer

The description for Event ID 0 from source SQL Server Connector for Microsoft Azure Key Vault cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Vault Name: vaultname.vault.azure.net Operation: Constructor Key Name: Message: [error:0, info:0, state:0] The Operation was successful.

the message resource is present but the message is not found in the string/message table

There are outbound network calls in firewall logs which connects to Microsoft Azure, and there are continous denials (resets) from Microsoft. The same setup works on our lower Test environment, just PROD is affected. Already raised this issue in another forum. https://learn.microsoft.com/en-us/answers/questions/1275244/sql-decryption-randomly-slow?page=1&orderby=Helpful&comment=answer-1245040#newest-answer-comment

  • Welcome to DBA. I think its the same as the other post. Duplicate questions tend to get closed May 19 at 20:56
  • What are the URIs for the resets? What is the longest response (including successful) for a conversation? Are the CRL endpoints allowed to be contacted through the firewall? etc. May 22 at 11:38
  • @SeanGallardy: We have IP that restting us. May 22 at 14:49
  • That doesn't help anyone here, we don't have any traces, we don't have any information other than what you provide. May 22 at 15:04
  • @SeanGallardy: This info from packet tracer may be of help. [No.]25 [Time]131.085490 [Source] [Destination] [Protocol]TCP [Length]58 [Info]443 → 57108 [RST, ACK] Seq=7779 Ack=2735 Win=0 Len=0 May 22 at 16:16


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.