I have inherited a SQL Server 2008 live server with a hot swap-able backup server which has transaction logs shipped every 15 minutes from multiple production servers. One of the production servers keeps getting out of sync, when I came it the last successful log restore on the backup was over a year ago... So clearly my predecessor wasn't watching this, I restored the database and ensured that the logs synced correctly at the next 15 minute interval. However, every couple of days or so (it is random sometimes an hour sometimes 3 days) it gets back out of sync and I have to spend 10 minutes of my morning restoring the database.
Basically I am wondering what I need to be looking at to figure out why these keep getting out of sync? I ran a query I found on sqlauthority.com which shows me the trn's and their license numbers for the primary database and when I try to just restore the transaction logs on the backup database with the file which is supposed to be the next license to get it back in sync it says the license number is too recent, so I try the next file and it says is out of sync and can't be restored.
Any help would be appreciated :)
Upon digging into the job history further I found that my LS_Restore job was succeeding with errors, which were that the sql server agent service account didn't have access to the folder the trn files were stored which it was trying to restore the database from.
I researched what the original developer had setup as the sql server agent service account and then granted that user the necessary permissions, the logs are now restoring as needed.
I hope this information helps someone in the future!!
Related
I am facing a strange issue with SQL Server 2012(Standard) Full backup job for the last 2 days.
Our database size is 1.3 TB and we are taking backups on a daily bases for all databases. From last 2 days without any error backups not happening. But I got job email alert with success in 13 sec.
I have checked on SQL server Full backup is running for last 10 hours.
Please suggest me for further.
I have searched in the error log and event viewer but I haven't found any error related to this backup job. And also I haven't found anything from job history as well it was showing last success history.
Anybody help me, How to take continuous backup from AZURE portal.(I don't have virtual machine in AZURE) It should be like scheduler running back side and will take back up from sql server in month interval.
SQL Database automatically creates database backups.
If you want it to create backup in month interval, you could upgrade your database service tier to Standard or Premium, SQL Database keeps existing backups until they are 35 days old. It keeps new backups as they occur for 35 days.
For more details, you could refer to this article.
i am facing issue in sql server Transactional replication and not able to get the root cause for it. First, let me tell you that i am not a DBA, so i may be dumb on few DBA concepts.
i am .Net developer and i have been given responsibility to setup the replication.
i have a Database in Headoffice and replicating few Tables to another server at retail Store.
First time, i configured the replication with selected articles.
the replication was continuous. it was running fine, but one Sunday night, it got failed with error "process could not execute 'sp_replcmds'".
after spending sometime on google, i couldn't find any solution. so, i rebuilt the Replication, but this time the replication was scheduled (every 15 Min), also i configured it as PULL instead of PUSH. it started, but again next Sunday night it got crashed.
So, i analyzed that in Sunday night, i had configured the Reindexing Job on the database, and Since, the recovery model was full, it was generating a very large TLOG and Repolication agent was not able to parse that.
Now, the third time, i again Rebuilt the Replication, and this time i scheduled the replication every 15 minutes but from 8:00 AM Morning to 11:30 PM, because after 11:30, no store do any transaction. Also, for Reindexing Job, i added 2 more steps. before Re-Indexing, i was changing the recovery model to simple and then Re-Indexing and after that i was changing the Recovery model back to Full. i was changing the recovery to Full, irrespective of the result from Re-Indexing step.
This setup was working fine and worked properly for around 2 Months.
Now, after 2 Months, again one Sunday night it got failed, with the same reason ("process could not execute 'sp_replcmds'"). Actually, i had scheduled the backup job, and i was taking Full Backup everyday and Log backup every 15 minutes, and no differential backup.
after, discovering that i had not configured the differential backup, i also configured the same (every 6 Hours). but, after configuring the Differential backup, in Sunday night Replication got failed.
Now, anybody, please help me with the recommended setup for my scenario.
my setup is
sql server - SQL Server 2008 R2 Enterprise on Windows Server 2008 R2
Distributor and Publisher are on same machine.
Subsriber is on the Retail Store server.
sp_replcmds is run by the log reader agent against the published database to get, well, replicated commands. According to the documentation, one needs to be at least db_owner to run that command. Make sure whatever account is running the log reader agent has at least db_owner in the published database.
I just migrated a SQL Server 2008 database while the sales staff went to lunch. I did a full backup and then copied the backup to the new server where I restored it to the new SQL Server installation.
The staff got back from lunch and told me that a few of the recent deals they put in right before lunch were no longer showing up in the system. Upon investigation it seems that the full backup was not including some of the very recent data that was added to the database before the backup was performed.
I suspect there is something I'm not accounting for that relates to the transaction log, but not being a MSSQL specialist, I'm not quite sure what I'm doing wrong. Could someone point me in the right direction?
Did you back up just the database, or with transaction logs as well? My guess is that you didn't backup transaction logs, which will contain recent transactions not yet flushed down to the mdb file.
The data may have been entered in an open transaction. Since the backup has to adhere to the ACID model, if a transaction was started before the backup started and was not committed by the time the backup has completed, the transaction will be rolled back upon restoring the database.
This is why you never do these things during a work day! Next time do this over the weekend and close the database off to users by putting it in single user mode. They could have added the data after your backup or during it if you didn't lock them out first.
I really need some help here.
I'm the owner of a SQL Server Database application that lost three days data! I can't understand how or why.
So here is the set-up.
SQL Server 2005 32bit standard edition database on Windows 2000 server. (Database B)
Database is in simple recovery mode
The database is connected as a subscriber to another database(SQL Server 2005 64bit enterprise edition on Win2k3 enterprise) using SQL Server continuous Merge Replication. (Database A)
DatabaseB was rebooted on night X as part of scheduled reboot. When the database came back up it was used as normal for a couple of days and data was created into it perfectly fine.
But then yesterday Day X + 4 it lost a lot of data.
Database B is on a server with another instance of SQL Server and they both started to run out of memory(conflicting with each other).
Here is the sequence of events from the event log when I think this happened.
AppDomain 2 (DatabaseB.dbo[runtime].1) is marked for unload due to memory pressure.
AppDomain 2 (DatabaseB.dbo[runtime].1) unloaded.
BACKUP LOG WITH TRUNCATE_ONLY or WITH NO_LOG is deprecated.
The simple recovery model should be used to automatically truncate the transaction log. (on DatabaseB)
AppDomain 3 (DatabaseB.dbo[runtime].2) created.
I know the data is missing because of my audit logs and that a user had taken a screen shot of some of the data before it was deleted.
So here is my dilema...how could this have happened?
How can several days data go missing from DatabaseB?? (it subsequently is missing from the publication db also!)
Did the truncate with the Appdomain down cause the data to be flushed from the log?
Any and all theories considered. If anyone needs more data I can add it.
Help!
This isn't the answer you want to hear, but in a nutshell, SQL Server doesn't "lose" data. Someone deleted it. If you had the database in full recovery mode, you could use a product like Quest LiteSpeed to read the logs and identify exactly how it was deleted, but in simple mode...sorry, sir, but you're out of luck.
Merge replication is implemented with triggers, so it doesn't need full recovery. Is it possible that someone disabled all triggers in the db? its easy to do DISABLE TRIGGER [database] This would at least account for the subscriber losing data.
Those appdomain lines in the log don't mean that much, its the SQL CLR telling you its unloading assemblies to free up some memory. & then reloading them later on.
Truncating the log removes inactive parts that have been committed to disk, having the recovery model set to simple means there's no point in truncating the log, as the message suggests.
None of this explains why data went missing on both the servers though. There has to be something else that caused this.
How did you verify that for the 4 days when everything was 'created perfectly fine' that it actually was? do you have backups from these days? can you see records with time stamps from those days?
Is it possible there's a ghost in the machine that did a restore without telling you?