• Check the sql server ERRORLOG file
• enable trace flag 3004 to show the internal backup/restore operation and more.

  This is an undocumented TF, so remove as soon as possible !

It's always nice to provide usable object models (ddl) with sample data and the actual queries, isolation levels, ....

That is indeed the best practice

That's exactily the reason why we scan and alert for such usage (use of own database name).

Do this for as well sprocs, views, functions, ...)

"Sloppy development" like "start from object...

HTH

Please provide feedback on your progress and solution.

The number of VLFs are to be seen per database and will be handled at startup/recovery time ( of the database, as a step in the startup of the instance...

What's the TARGET_RECOVERY_TIME and recovery interval that has been configured on your databases ?

added: How many VLFs are to be handled for your databases ?

• This reply was modified 12 months ago by Johan Bijnens.

Are there indications for the slow operation in the sql server errorlog files?

Is the always on node involved with the clustered sqlserver instance ?

if yes, are you using a listener...

Is this a clustered sql server instance ?

Is this a db involved in an Availability group ?

Is query_store active ?  ( did you implement trace flags 7745 / 7752 )

What's...

did you install SQLExpress to host your localdb ?

( Maybe even during your VS2022 install )

ref: "Tutorial: Configure replication between two managed instances"

Exactly THE reason why we avoid linked server usage as much as possible !

SQLserver itself determines "where" the linked server part of the query is being executed.

It may as well...

Do you mean "Azure Managed instance Link" ?

Check the windows folder security at the new location and double check the service account has the needed authority !

double check which account your service is trying to use !