I have an Azure SQL Managed Instance and have noticed that database creation and deletion not only takes a long time, 3 minutes to create a new database and up to 5 minutes to then delete that database, but that those times can also fluctuate a lot too. What is the reason for this?
When a new databases are created their files are initialized on Azure Premium storage (which is remote storage) including initial backup so they can be ready for HA, and also they need to be registered in Azure Management Service that controls availability of database. This is not instant, but in most of the cases it should be under a minute. I'm frequently creating databases and I don't remember any case when it was longer than 10-15 sec.
For delete operation you can expect up to 5 minute delay, because we are waiting for the last log backup to be taken (log backups are taken every 5 minutes). In the future we might initiate tail log backup immediately when the DROP DATABASE is executed, but in the current version Managed Instance waits for last backup.
Related
When I try to take back-up of an SQL server database (around 1000 GB) the time taken for the process varies each time.
Sometimes the back-up process completes within 70 mins and some times takes around 3 hours or so.
What could be the reason for the variation in backup times?
Can someone tell me the factors which influence the back-up time in SQL Server and the steps that could be taken to reduce the backup time?
Here are the details of the server box from which the backup is initiated:
MS Windows Server 2012 R2 Standard
Processor with 2.60 Ghz frequency
RAM - More than 300 gb
Additional info: All drives are SSD and back-up is taken with compression.
The back-up target is a remote network location carried out over a 1 GBPS bandwidth network.
So 1000 GB is the total size of DB datafiles, what about transaction log files ?
Are transaction log(s) included in your backup ?
A Database can be using a simple recovery mode, so basically nothing is written on the log files, or can be working with logfiles which are keeping db changes not committed.
Once they got committed the transaction log generally stay there (and grow) until a full backup with the flag to truncate log is completed.
According to the workload the size of transaction log files can vary a lot from one backup to another one despite the Database size changed slightly so the total data to be backup up can vary a lot too, and obviously the time to complete the full backup process.
In my experience the backup when there have been almost no user activity, i.e. on Sunday evening, are a lot faster of the ones after a certain number of transaction due to the increased size of logfile.
I am in need of some help.I want to reinitialize one of my subscribers with a new snapshot.my previous snapshot i generated was when activity was low on the production database.It took under 2 minutes.
My question is,can i generate a new snapshot during the day when the applications are using the database live? would it lock my tables badly to where transaction wont be followed to the database?
Yes, you can create initial snapshot during the day.
With transactional replication Snapshot Agent takes locks only during the initial phase of snapshot generation.
Performance impact of this operation depends on current workload of your system. So, if previous snapshot generation took 2 minutes, I think I will take not much more time.
I am not a DBA, but have recently been charged with monitoring my companies DB. A merge that normally takes 12-18 minutes is now taking over 2 hours. This was setup by a DBA and I am told that all the indexing was done correctly. I found in the activity monitor that the process is hitting a PAGEIOLATCH_SH/EX wait type and the Resource Waits - Buffer I/O wait times are above 3000 (I cant find a baseline to see if this is normal...but it doesn't seem to be). Does anyone have any information on where I could go from here? I have already tried restarting the SQL server and force re-compiling the stored procedure that calls the merge. We are not working with an massive DB only about 2 million rows or so.
I have been a lurker for several years and I think I have a question that hasn't been answered here.
We were in the middle of some pretty intense maintenance on or SQL server last night. Or primary database mdb file was very badly fragmented. We maintain a test copy of this database for testing and proof of concept purposes.
I had setup log shipping on the test database and without thinking I deleted the test database without removing the log shipping first. I am getting error 14421 - The log shipping secondary database SERVER.database has restore threshold of 45 minutes and is out of sync. No restore was performed for 10310 minutes. Restored latency is 0 minutes. Check agent log and logshipping monitor information.
I have removed everything I could with tsql. My research leads me to believe that this error is due to the backup job still trying to operate but I cannot find this job to remove it. It's really not a big deal but the error shows up every couple of minutes in the log.
Is there anything I can do?
Thanks in advance!
Log Shipping Information is stored in MSDB, not in the database itself. All you need to do is create a new database with the same name as the deleted database. Right click for properties, log ship tab and then uncheck the box to log ship the database. When you click okay the jobs(on primary and secondary) will be removed.
I have an SQL database which has a main Orders table taking 2-5 new rows per day.
Other table which has daily records is Log table. It receives new data every time a user accesses the login page of the web site including time and the IP address of the user. It gets 10-15 new rows per day for now.
As I monitor the daily backup of SQL, I realized that it is growing like 2-3MB per day. I have enough storage but it makes me worried. Is it the Log table causing this growth? I deleted like 150 rows but it didn't cause the .bak file size reduce. It increased! I didn't shrink database and I don't want to do it.
I'm not sure what to do about it. Is there any other decent way of Logging user accesses?
I typically export the rows from the production server, and import into a database on a non-production server (like my local machine), then delete the existing rows from the production server. Also run an optimize on the production server table so the size is recalculated. This is somewhat manual but it keeps the production server table size down, and the export/import process is rather quick.