Now guys we all know that leaving a blank password around is dangerous, storing it in an ini file is just as bad and using the SA account is worse still. Security one day people will wake up and smell the roses because they have been buried in manure.
]]>So what is a spray, in Australia coaches at quarter, half and three quartertime talk to the team sometimes this becomes a spray.
Here is a typical one delivered by the coach to a local football team.
“You blokes are jokes! Don’t you want to win? You need to go into the room of mirrors and have a good, hard look at yourselves. You have let the team down! You’ve let the club down! You have let Tigers fans down! You have pissed on the Tigers’ jumper. You have dudded your families and, most importantly, you bludgers have let the whole of the Barossa Valley down.
So I will be spraying at lots of different issues all faced with SQL Server
My First Spray is to Microsoft
Why in all this time have you not fixed the security on VDI, for those that don't know all third part backup tools use the old legacy technology that is VDI to communicate with SQL Server to perform their backup. The problem is that to do this the user/account issuing the commands for backup must have sysadmin rights. Under database roles we have db_backupoperator which can be a member of public but a user without sysadmin level cannot use the VDI backup set only the Native Backup.
This is a security issue and has been around since SQL Server 7 its time Microsoft fixed this, possibly introduce a server role for backup operations that an account can be assigned to allowing a senior level dba to lock down the server even further.
It would then be possible to stop unauthorized database backups, monitor specific accounts doing backups and remove the need for a user to have sysadmin privileges unless required.
]]>
Many people think Log shipping is a type of high availability solution that is a much cheaper solution than clustering however log shipping does not replace clustering. Clustering allows fail-over through the redundancy of the hardware and the OS not the SQL data. If you want High Availability for the SQL data look at Replication or synchronous mirroring. Log shipping is really more Disaster Recovery, which is used to enable you to recover from a disaster whether the disaster is external or internal etc.
Think Log shipping keeps the two servers in Sync -- wrong! Log Shipping occurs at the database level and not at the SQL server level so anything that is changed in other areas of the SQL Server such as configuration changes, OS changes will be unknown to the database that is been log shipped.
What is Log Shipping?
Log shipping is the means of establishing a warm backup solution by using the SQL Server Native or third party utilities to transfer and restore logs between databases.
Log shipping is a Disaster Recovery strategy for databases and nothing more. It does have some side benefits. For instance, the database that is on the standby server can be used for reporting, which is a good thing. If a production database fails, all you have to do is point the users to the standby server, and you are all set. Well, it’s not really that simple, but it comes close if you put enough effort into your log shipping setup.
So why use Log Shipping?
In today’s world, business cannot afford disruptions to applications, web sites or information. Most of the data stored for these areas is found in backend databases. So as good DBAs we look at ways of making our data safer by using standby servers to have a copy of the database either onsite or offsite. If the worst occurs we can swap to the standby server and be back up and running in next to no time.
Log shipping is actually the process of backing up the transaction log for a given database and sending it to another server where we restore. If the time between backups is minimal (the default most DBAs tend to use is 15 mins) than we only risk a limited amount of data loss if something goes wrong.
The Pit Falls of Log Shipping that DBA’s forget.
Imagine you’ve gone to the trouble to implement log shipping and now it is time to bring the standby server online due to a problem with the primary server. You know you are safe. You’ve gone through the documentation from Microsoft and everything looks sweet, right? I’m afraid to tell you there is a lot more to it than just shipping the logs.
Let’s look at what log shipping does not do. It does not ship any SQL Server Objects that is the SQL Jobs, the SQL Maintenance Plans, the SQL Server Security settings and so on, it only ships the DATABASE.
So to bring your standby server online you need to run through everything that has occurred at the server level that will affect that database.
The Problems that DBAs face with Log Shipping.
There are 2 main problems DBAs face with log shipping.
•1. A standby server needs to be managed, updated, and maintained; so you need to allow time for this and you need to plan for the cost of replacing the standby server as the equipment gets old.
•2. The process of failover is not automatic. You may even want to try restoring the tail of the log before you bring it online therefore reducing data lose to nothing.
We can overcome a lot of these issues by restoring master and MSDB on the Standby Server, but wait, what if you are using the standby server for to protect other SQL servers or other databases? It all starts getting very tricky. Consider this, SQL server logins will need to be synchronized from the primary server to the standby server.
I love log shipping for what it can do, but with the advent of Virtual Machines, I have been looking at how to restore the entire server or critical parts to virtual.
If you break your SQL Server into parts, you can see how a virtual image of the server can work very easily for you. The server hardware usually includes the system and application drives since the data and log drives are normally on a SAN. So if my server breaks, I need to identify if it’s just the system and application drives that I need to get back up and running or if it’s the SAN for my data and logs, or if it’s both. (Of course if you are a smaller, non SAN, shop, the data is local so it really is the restoring of both areas at one time.)
In these times where companies are trying to reduce infrastructure costs and postpone the purchase of new equipment, we as DBAs need to start looking into newer technologies to resolve our protection needs. We need to be more eco-friendly by using less electricity and having a smaller foot print on the environment. One way I have found is using AppAssure’s Replay AppImage for Disaster Recovery. It has the ability to restore from its backup images either to a Virtual Machine or to new hardware in minutes. It also has the unique ability to continuously restore to a Virtual Machine that can be powered on when required. So do yourself and the environment a favour and visit there website today http://www.appassure.com/Home.aspx
]]>Resources for Performing Benchmarking
TPC is a non-profit group that publish benchmark tests and results
Benchmark Factory they have a freeware version which is a great start
Microsoft has a great TechNet article on Predeployment I/O Best Practices which is great for understanding the performance capabilities of your Disk I/O
]]>As DBA’s we need to stamp out this practice and tell our companies/customers that this is a significant security risk and should not be accepted. In some ways it goes to show how hard it is for non SQL Server people to implementing a proper security structure for a data base.
Things I look for in a good implementation.
•1. No user access to tables
•2. Users can only access ad-hoc queries through the use of views
•3. The third part application or web site uses stored procedures for all its access of the data
•4. Windows Domain accounts are used preferably
•5. The application includes its name in the connection string
•6. Public access is disable at database level
•7. Control of access to stored procedures and views is controlled by roles
•8. Schemas are implemented in database that have a variety of user access like HR applications
•9. Disable or Remove Guest Access on the Database
This is just a start feel free to add to the list send me an email etc and I will keep it updated.
Remember any application accessing the data directly, using ad-hoc sql, using the server sysadmin role or using the sa account is a security risk and should not be tolerated in your organization.
I have two exceptions for the sysadmin rule and that is backup application and server monitoring tools although you have to really check them out to understand any vulnerability that they may cause you.
]]>
The real issue the System Engineer was having was the server could cope with the traffic for 95% of the time but for high peak periods the server would slow to a grind because of high usage by users from different areas. When you looked at the workload there were three distinct user groups, data entry operators, back office staff doing normally daily transactions and management running reports. The bottleneck always occurred when management required reports and in reality the queries that they were running were not complex but required lots of summing, counting, totals etc. What the company really required was a Data Warehouse that would be updated once a day to slice a dice the data based upon known reports to elevate the performance degradation. In actual fact by using reporting services most of the reports could be delivered to management via email before they arrived into the office. I’ll let you know the outcome as they progress.
]]>
http://www.sqlcompression.com/
Beta Testers Required : beta@sqlcompression.com
]]>
Have you ever been faced with the daunting cry of help from a DBA because SQL Server won’t start? The reason for the failure is due to a corrupted master and the DBA has never restored master before. If you have, then you know the situation is daunting to them as it is not a straight forward process to get SQL Server up and running.
Considerations for Restoring the master Database
If you or your team has made changes to master since a backup was created all those changes will be lost when master is restored. You must redo all your work on that SQL Instance by executing the statements that you hopefully saved when you made those changes. For example, if any SQL Server logins have been created since the backup was performed, the logins are lost when master is restored. Re-create the logins by using SQL Server Management Studio or by using the original scripts with which the logins were created.
An outline of the steps:
1. Locate media with SQL Server Install.
2. Try and remember the configuration for the SQL Server collation order last hot fix etc. because I bet you never document them when you are updating the SQL Server.
3. Find the last backup of master (master can only have a full backup) makes life simpler but alas any changes that you have made since the last backup are gone forever hope your memory is good. Also locate backups for model and msdb or copy the current ones to a safe spot you will need them also as you don’t won’t to recreate all your SQL Jobs etc since the last backup.
4. Run the SQL Server setup.exe from the command prompt like this:
Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=InstanceName /SQLSYSADMINACCOUNTS=accounts /[ SAPWD= StrongPassword ] [ /SQLCOLLATION=CollationName]
5. After the rebuild operation is complete, examine the SQL Server logs for any errors.
6. Apply the service packs and hot fixes.
7. Start the SQL Server in single-user mode
8. From the command line run sqlcmd and restore the database like this:
RESTORE DATABASE master FROM <backup_device> WITH REPLACE
9. Restore MSDB and Model from backup or go to step 10 if you are copying them
10. Stop SQL Server
11. Replace MSDB and Model with your copies if you did not restore them
12. Restart the service.
For a full description of the restore process look at these two MSDN articles from SQL Server Books Online:
1. http://msdn.microsoft.com/en-us/library/ms175535.aspx
2. http://technet.microsoft.com/en-us/library/ms190679.aspx
So why am I making all this fuss about restoring the Master database? I’ll tell you why. Because it is crazy and way harder than what it needs to be. The above situation takes me just over 30 mins to complete if everything runs well and normally takes me about an hour. And I keep good backups. I have seen situations where DBAs only backup master once a week and even where they have excluded master, msdb and model from all backup schedules. Even I normally only backup these DBs on a nightly basis, which means I leave myself open to having to recreate a day’s work if things go wrong.
An Alternative Approach
Well I have been working with a customer on their backup strategy and found AppAssure’s product Replay AppImage. I must admit it really fills a gap. Based upon Shadow Copy, a Microsoft technology, it takes snapshots of the server’s drives at 15 min intervals stores them on a LiveReplay Server allowing you so much flexibility with the restore process. You can restore to a new server, to a virtual server, restore a drive, mount a drive locally so you can copy files, etc. To restore master with Replay AppImage, instead of following the steps above you just use the mount and copy function. It took me just under a minute and that included remote desktop to the server. All I had to do then was restart the service and I was up and running with only 10 mins of lost time.
An Outline of the Steps with Replay AppImage:
It isn’t the only tool in my SQL Backup Toolbox but in this instance it really makes my day. If you think it might make yours, take a look at the product and put it through some tests. I will be adding more test outcomes up here shortly as we ran a multitude of them of them to work out our backup strategy.
http://www.appassure.com/Home.aspx
]]>