January 15, 2014 at 1:49 am
Steve Jones - SSC Editor (12/26/2013)
Brent Ozar (12/26/2013)
Why is it headline news that you agree with me, Steve? Are you saying you don't always agree with me, is that what you're saying? You'd better not be lying to me when you say you listen to Hall & Oates all day, every day just like I do. You're out of touch, I'm out of time.We probably agree more than we disagree, but in this case I thought I'd point it out to others.
I haven't listened to, dressed like, or had hair like, H&O in a long time, though my wife likes their music.
I think you could file for divorce on the grounds of mental cruelty.
January 26, 2014 at 12:36 am
I enjoy SQL Server more for the included Tools than anything else. SSMS is a Great Tool as is SSIS.
The SQL Server Database Engine is still stuck in PC Land. My unexplainable Errors are now down to about 1 in 3 months. By this I mean Errors that don't make sense and are solved by a restart.
My other Database Platform is DB2 on i. Unexplained Errors don't happen. Restarts aren't needed. This is the real difference between SQL Server/Oracle vs DB2. As mentioned by an earlier poster 24x7 is real not just a target.
Regards
January 27, 2014 at 7:58 am
At my current job, we had a major application (our police department) running on the same DB2 i series box for 18 years. The box never went down for maintenance and never failed during that time. That would be a noteworthy feat for a mainframe, of which I have 25 years experience. But the i series would correspond more as a mid-level server when it was installed. But alas, our application got upgraded and the platform of choice was Windows/SQL Server. It is running pretty well ***now***, but we have had our problems.
Please don't take this as bad mouthing SQL Server. Today SS2012 is a very robust product. How it works out for you depends greatly on your technical architecture. If the architect cut corners, yep, you as the DBA (and ultimately the business) will find out the hard way.
With your post and this reply, I am hoping for others to see a perspective -- both from a company perspective as well as a platform perspective.
Regards, JMD
January 27, 2014 at 9:14 am
Never had SQL run for 18 years, but I have had it run for 2. The problem I've most often seen with long running SQL stuff is Windows. Too many patches there. You can make this work with a cluster and come patches, but that's a higher level of work than most companies need.
Do patches for the iSeries or DB2 not require downtime? When I had DB2 on AIX, we still occassionally had patches that required some restart.
January 27, 2014 at 10:05 am
We had an instance of SQL Server 7 running on a Windows NT box for 10 years without a reboot. Granted, the server did not do much heavy lifting. We never had a Windows 2000 or newer server that has not had to be taken down at least once though. We eventually took down the NT box when we revamped the reporting system and it was no longer needed. Had we not done that, it might still be running today. I agree with Steve, for us Windows has required more maintenance than SQL Server due to the patches. The longest we have had a SQL 2000 server run without maintenance was 3 or 4 years. But that was on a Windows 2000 server. It seems our Windows 2003 and Windows 2008 boxes have required more updates.
January 27, 2014 at 10:29 am
No on the patches requiring downtime on the i Series. Same thing on the mainframe since the typical configuration allows for disk sharing across (up to) 32 separate boxes. You simply take one box down for maintenance and the others keep on truckin'.
That is why when a vendor says today that their hardware/software supports 24x7, you have to ask a follow-up question, "Does your product support *continuous* availability of the *application*?" There is no wiggle room on that question. I have heard 24x7 meaning the box can run 24x7 without *unscheduled* down time, or the hardware can run 24x7 but the OS can only run 24x7 without unscheduled downtime, etc. But can the application continue to run without any down time? Until recently, this was very difficult for the vendors to state this. It takes a lot of duplication at the database server level, the application server level, and the web server level. You will have to employ a type of transactional replication as well at the database. How you run application changes that require objects to be unavailable is fairly complex as well.
So when the business demands 24x7, you have to educate them. Your response should be, "Yes, but do you really know how much it will cost you?" And the cost isn't limited to the production environment. If the application is really as important as the business is stating, your QA environment has to play along with all the duplication. Continuous availability usually is an order of magnitude more expensive than a technical architecture which is somewhat more forgiving. Nine out of ten times in my experience when the cost reality is made clear to the business, they will find another way to let allow for some type of downtime.
In fact, my current bank doesn't hesitate to put a splash screen up on their web server on Saturday nights telling me that the server is down for maintenance. Do I mind? No. I understand that by waiting until the next day it can save an enormous amount of money (of which cost would be passed on to me).
January 27, 2014 at 1:51 pm
Saying "it's not the platform" is not at all the same thing as saying that a given application can be ported to a different platform without issues. Anyone who would expect that situation to turn out happily pretty much deserves what they get.
I've been involved in writing software with an Oracle back end, I've done the same for SQL Server, and I've been involved in building systems that are intended for both. It is a HUGE mistake to think that a single code base (data access) can deliver adequate performance in both.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
January 27, 2014 at 1:55 pm
Steve Jones - SSC Editor (1/27/2014)
Never had SQL run for 18 years, but I have had it run for 2. The problem I've most often seen with long running SQL stuff is Windows. Too many patches there. You can make this work with a cluster and come patches, but that's a higher level of work than most companies need.Do patches for the iSeries or DB2 not require downtime? When I had DB2 on AIX, we still occassionally had patches that required some restart.
In my experience, truly lengthy uptimes like this are only possible if you don't apply updates. I've personally been involved with several Oracle/*ix systems that had lengthy uptimes but were years out of date. Maybe it doesn't matter for the application in question, but in these cases the update hadn't been applied because of a mixture of not wanting to mess with their uptime numbers, and fear...
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
January 27, 2014 at 2:05 pm
Our IBM i Systems are hosted by IBM so they definitely do get patches applied.
When I was alluding to 24x7 and reliability I was referring to Errors that only go away when the System is restarted.
David
January 27, 2014 at 6:18 pm
DCPeterson (1/27/2014)
I've been involved in writing software with an Oracle back end, I've done the same for SQL Server, and I've been involved in building systems that are intended for both. It is a HUGE mistake to think that a single code base (data access) can deliver adequate performance in both.
Well I worked with PeopleSoft's Accounting SW. What most people don't realize that they code it with both Oracles and SQL Servers statements and which code is used dependent of the config files.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
January 27, 2014 at 7:04 pm
Jim P. (1/27/2014)
DCPeterson (1/27/2014)
I've been involved in writing software with an Oracle back end, I've done the same for SQL Server, and I've been involved in building systems that are intended for both. It is a HUGE mistake to think that a single code base (data access) can deliver adequate performance in both.Well I worked with PeopleSoft's Accounting SW. What most people don't realize that they code it with both Oracles and SQL Servers statements and which code is used dependent of the config files.
Aspect eWorkForce Management software is coded the same way. Unfortunately, that means we have to deal with a case-sensitive DB. I have only ever installed it on SQL Server but it looks like the Oracle code is nearly identical.
January 27, 2014 at 7:24 pm
KWymore (1/27/2014)
Aspect eWorkForce Management software is coded the same way. Unfortunately, that means we have to deal with a case-sensitive DB. I have only ever installed it on SQL Server but it looks like the Oracle code is nearly identical.
Having done both Oracle and SQL -- they both are pretty close in the DML stuff.
The systems variables change, as well as the temporary objects.
It it the DDL that seems to have the most variation. Such as Create table xxxx as select from compared to SELECT * INTO xxxx from.
But the application has twice the size for doing the same thing.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
Viewing 12 posts - 16 through 26 (of 26 total)
You must be logged in to reply to this topic. Login to reply