MIS Systems Thread, Backing up SQl transaction logs (starting to panic) in Technical; Apparently, and this is odd, I can fix the login password issue by restoring the database (bak) using SQL, then ...
25th June 2014, 09:39 AM #31
Apparently, and this is odd, I can fix the login password issue by restoring the database (bak) using SQL, then use dbattach to export and then re import the database which apparently fixes the user logins. Going to test this next week.
25th June 2014, 10:39 AM #32
Yep, it's described in that document that they linked you to and that i referenced. If the passwords are stored in the database as a result of detaching the database at some point, then you can restore a backup of it.
Alternatively you can just run a stored procedure that will copy the latest logins into the database for you, so that they will be up to date for future backups.
It's best to limit detach-attach cycles simply because it's too scary and not necessary.
I'm sure ages ago there was a change request to add command line options for these procedures into dbattach, but it got lost and is probably obsolete now since the cleanup of supportnet.
25th June 2014, 10:44 AM #33
The best way to put your mind at rest on this would be to check the size of the ldf files for your databases. If the LA solution is not correctly backing up or checkpointing the transaction log then these ldf files (these are the files that contain the transaction log itself) would just keep on growing. It would depend on how long the backup solution has been in use for and how much data gets changed in your database as to how big "big" would be, but as a rule of thumb if it's bigger than your database file it's probably not being dealt with correctly. In this case, as others have suggested get back to your LA and report the large transaction log file as an issue and get them to fix it.
Also, even with a database that is in a Full recovery model you can still restore (to the point at which the backup was taken) even without having taken a transaction log backup alongside the main backup, but you would lose differences that the transaction log would have been storing for you, so even if the setup was not correct you wouldn't be completely unprotected.
The problem with the Full recovery model is the potential that your transaction log files grow out of control and either fill your disk (very bad) or hit the maximum file size limit set on that file (also pretty bad). The result of this would be that the SQL server could no longer add or update data in your database, which would generally mean that your MIS system would start spitting out a whole bunch of errors - I'm not sure exactly which errors SIMS would give you at that stage, but you could probably expect to see almost anything and it would likely be related to the lack of tlog space. Full recovery is safe so long as your transaction log backups continue to happen, and so long as your on top of checking your backups you'll probably spot an issue with it pretty quick.
25th June 2014, 11:14 AM #34
The really frustrating thing about it is the amount of time we've wasted talking about it vs the half and hour it would take to code it in, heck, waste an afternoon on dbattach and you could get it to restore SOLUS3 and Discover databases as well!
Originally Posted by vikpaw
25th June 2014, 11:28 AM #35
Originally Posted by matt40k
@SkywOrca the error, if it's not reason 0 would be fault code: bad-da7a-dead-feed
By RabbieBurns in forum Enterprise Software
Last Post: 5th March 2012, 12:18 PM
By glennda in forum Windows
Last Post: 6th August 2010, 12:19 PM
Last Post: 8th June 2006, 09:36 PM
By Cyber-Dude in forum Windows
Last Post: 26th May 2006, 10:01 AM
Last Post: 23rd May 2006, 11:29 AM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)