August 29, 2008 at 9:35 am
Loner (8/29/2008)
When I pointed out her mistakes, her boss complained to my boss that I was a difficult person to work with!!!!! Oh well!!!!
Did you rat her out?
Let me guess... she wasn't pretty and... you definitively are a "difficult person to work with" 😀
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.August 29, 2008 at 9:59 am
when you delete a file, regardless of the recycle bin, the file is still there, but the disk space it used is open for use by other programs...if you hurry and grab an UNDELETE utility, you might still have a chance to recover the mdf and ldf files. google undelete and try any of the utilities you find.
Lowell
August 29, 2008 at 10:31 am
google undelete and try any of the utilities you find.
But don't install them on the same drives where the mdf and ldf files used to be located on. In fact, don't do anything on those drives.
SQL BAK Explorer - read SQL Server backup file details without SQL Server.
Supports backup files created with SQL Server 2005 up to SQL Server 2017.
August 30, 2008 at 1:43 am
Oh I feel sorry for that guy. But I surprise how the database can be deleted when it is in use. most of the production db's will be continuously in use. And wht happened to your backup. Dont you have proper disaster recovery strategy.
[font="Verdana"]Thanks
Chandra Mohan[/font]
August 30, 2008 at 9:16 pm
Lowell (8/29/2008)
when you delete a file, regardless of the recycle bin, the file is still there, but the disk space it used is open for use by other programs...if you hurry and grab an UNDELETE utility, you might still have a chance to recover the mdf and ldf files. google undelete and try any of the utilities you find.
Spot on, Lowell!
--Jeff Moden
Change is inevitable... Change for the better is not.
August 31, 2008 at 9:35 am
You should probably read the security sections in Books Online to understand this. Not to beat on you, and I know you just want to get something working, but not understanding security and just getting bare minimums setup is one reason we have so many security issues today.
http://msdn.microsoft.com/en-us/library/bb510418.aspx
Login - You need one setup to connect to the server. You can use a Windows account and set that in IIS, and I'd recommend that.
User: You map a user to the login, you can do this when you create the login, I'd keep them the same name.
Roles: Create one. You might think you'll only need one user, but you never know. Just create a role and add the user from above to it.
Permissions: Choose the role, add permissions to each sproc and then insert/update/delete to tables. Note that I'd add the GRANT XX to (role) to each statement as I built objects just to be sure that they were there and you had good version control of permissions. If you only use the GUI, this should be a step you take with each object and I'd be sure you script out the objects periodically and drop that in a VCS.
August 31, 2008 at 9:35 am
If you get something to work, I'd be interested to see what happened here.
And good luck
August 31, 2008 at 10:07 am
Steve Jones - Editor (8/31/2008)
You should probably read the security sections in Books Online to understand this.
This in the wrong place?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 1, 2008 at 3:56 am
Fearless and clueless is a very dangerous combination...
What he should have done is of course to detach the DB, move the files and then attach the DB with the files in their new location. But even then, he should have had a backup before tampering with a production DB. Bad things can happen anytime, anywhere - especially when people are involved.
But another thing I don't understand is - why did the physical location of the files determine whether you got a backup or not? This sounds fishy to me. You need to have a backup of the database itself, not just a plain file backup. The actual location of the physical files shouldn't matter if this is set up right.
Vegard Hagen
Norwegian DBA, occasional blogger and generally a nice guy who believes the world is big enough for all of us.
@vegard_hagen on Twitter
Blog: Vegards corner (No actual SQL stuff here - havent found my niche yet. Maybe some day...)
September 1, 2008 at 6:33 am
Vegard Hagen (9/1/2008)
Fearless and clueless is a very dangerous combination.
ohh so true!
Vegard Hagen (9/1/2008)
What he should have done is of course to detach the DB, move the files and then attach the DB with the files in their new location.
you dont need to detach the database to move the files. Set the database offline and use the alter database statement to move the file locations, copy the files and then set back to online 😎
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
September 1, 2008 at 6:42 am
Lowell (8/29/2008)
when you delete a file, regardless of the recycle bin, the file is still there, but the disk space it used is open for use by other programs...if you hurry and grab an UNDELETE utility, you might still have a chance to recover the mdf and ldf files. google undelete and try any of the utilities you find.
this is prob about your only hope, but sadly if SQL server is still running and other database files are growing the deleted files could well be lost, might be worth a go though!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
September 3, 2008 at 12:41 pm
Anyway,
he had to sign a paper... one strike...
still there is no backup job that runs SQL on the regular basis. DB files just get backed up physically on the tape (SAN) somehow.. no disaster recovery plan.. and so it goes ... 😉
September 3, 2008 at 12:46 pm
Then implement some backup jobs. Next time it could be you getting the written warning, or fired. You won't be able to say 'I didn't know there weren't backups'
If the file backups are run on the SQL databases while the sQL service is running, there's a very good chance that those backups are useless.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 3, 2008 at 1:15 pm
GilaMonster (9/3/2008)
Then implement some backup jobs. Next time it could be you getting the written warning, or fired.
Yup. It only takes a couple of clicks in the GUI, and deciding on a location to place them. Less time than it took to post in this thread.
Then put those backup files (*.BAK) to tape instead.
I don't know the structure of your organization, but whoever has a job title closest to "DBA" seems to be asking for trouble.
September 4, 2008 at 6:14 am
It is possible to get a good backup of SQL Server databases using block level copy, providing you do all the right things. If you miss something out, you are most likely to end up with SQL saying the database is corrupt.
To get things right, you need to consider what happens if the power fails for a server while SQL is running. In this situation, the data in the MDF and LDF files is consistant - the LDF will know which transactions have been committed, which are open, what LRSNs should be on MDF pages associated with incomplete transactions, etc. When you restart SQL after a power failure, it should do the standard roll forward to the end of the log, then roll back incomplete transactions to get the MDF file to a stable state.
If you use block level copy, you must get the same level of consistency or you will not be able to get a working recovery.
This means all the disks holding your data and log files must be in the same SAN mirror group. This will allow a script to suspend the mirroring for the whole set of disks at the same time, simulating a power failure on the server. The frozen mirror can then be backed up using block level copy. After the backup is complete, re-enable the mirroring. You need to test this process a number of times with different databases to make sure it works for you. Even if it does work, you need to be aware this process is inherently more risky than taking normal SQL Server backups, as any small difference in timing the freezing of the mirror on the data and log disks will give you an non-useable backup.
If you do something different, like suspend the mirror on the data disks at a different time to suspending the mirror on the log disks, then you will have an non-useable backup. If you just take a block level copy without using a frozen mirror, you will have a non-useable backup.
The only truely safe way to take block level backups of SQL Server databases is to stop SQL server while the backups are being taken.
So, if your SAN people have the right skills then block level backups while SQL is running are possible. Even so, my recommendation is to always take SQL Server backups then use the SAN to take a copy of these backups.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 15 posts - 16 through 30 (of 47 total)
You must be logged in to reply to this topic. Login to reply