A vs B, part I

Just finished the first SQL Server dba training.


There is a lot to be said, so I'll have to split this into multiple posts. And I still NEED to catch up with Kevin's important stuff on SAN's and NAS/NFS! I need 48 hour days...


Anyways: those of you who know me from the c.d.o.s days will recall I didn't use to take lightly to Microsoft's wild claims about SQL Server. And that was definitely the case until SQL Server 2000.


That was then. Now, there is SQL Server 2005. Or, as I prefer shorter monikers: SSr9. Because it is indeed release 9 of this product.


And to me at least, it looks like Microsoft has for once actually LISTENED and done quite a few useful things with the product. And it has done so in a way that is not only easy to use but also DIRT EASY to learn!


Instead of the usual marketing patina it uses to mask clear inadequacies of its product range.



So: what is it that strikes me as so much better?



Many things. I will resist as much as possible extensive, exhaustive "A vs B" comparisons: it is really not applicable as in my view SQL Server is targeting a different market than Oracle is in.


To Oracle's clear detriment, but that will be the subject of a later post.


Although of course the marketeers from both sides will claim the "same universe" and all sorts of "competitive advantages" for each side. Please, just ignore that mob: they are truly useless, in this day and age of mixed supplier data centres.


The naked truth is: at the base kernel product level, Oracle walks all over SQL Server. Simple as that, folks.


It's the block size tuning, it's the fine memory tuning, it's the fine optimizer nuances, it's the much better control over disk space, it's the much, much better space management and maintenance, it's the...


like I said: I'll refrain from extensive item by item, point by point comparisons.



HOWEVER...


Life is not just the base product, folks. It's much more than that.


Fact is: Oracle's fixation with the "web paradigm", java-based and web-based technology for its ancillary toolset has left them at a clear disadvantage in what regards the flexibility and ease of use of things like OEM, grid, rman and all such ancillary tools.



Which you MUST learn in detail in order to effectively extract all the power out of all the base product advantages!


This is compounded by the much more complex administration and maintenance required by Oracle's advanced features, compared to the much more basic SSr9 ones.


Don't get me wrong: if you invest the time - and money: never forget those two are closely linked! - to train in the somewhat cryptic and ultra-complex Oracle db management tools and their quirky UIs, you can definitely take advantage of the power inherent in Oracle's superior implementation.


But if like so many others you have two or three management layers above you breathing fire down your neck every time you can't flick the mouse and solve the world's problems with a few "swish and clicks", you will absolutely, positively and completely LOVE SSr9's management UI: the SQL Server Management Studio.


For starters: it's a true GUI. With a functionaly rich and truly friendly user interface. Not the rubbish "web paradigm" we've had to cope with in Oracle for the last 5 years.


This may come as a surprise to the web-boffins inside Oracle, but the vast majority of the web is - most definitely! - NOT a good example of user friendliness!


In fact, the opposite is much more likely to be the case!


I'll take the ease of use of the Windows or Linux GUI over the "web paradigm", any day or night. Without even flinching!


For example: there is a HUGE difference - for the better - between generating a command-line script equivalent of my current dialogue box with a single click, and the "click here while holding that and remembering to go back three screens - oh, did you remember to flick the checkbox and the radio button two pages ago?" confusing and unfriendly interface of the web-based OEM and grid.


By the same token: in Oracle, you know of course how many process steps I have to follow to backup a given database online. I have to check first if it is in archive log mode, don't I? And then make sure that I remember which and where the archive redo logs are, taken during the backup.


Don't I? Ah yes: RMAN, I hear you say?


You mean that quaint command line stuff with "connect target as /" - ain't that user-friendliness?... - before I can do anything else?


What was that again? Ah yes, the ORACLE_SID. Sorry, I forgot to set it first. Darn...


And have you checked the RMAN manuals of late? Four. No less!...


Well, it's again one single right-click with SSr9. Simple as that, folks. r-click, backup. Up comes the dialogue. With EVERY SINGLE POSSIBLE option available to control backups. Cross-checked and automatically consistently set, based on the current settings of my instance. Available for me to fine tune via radio buttons, drop-down lists and all such. Then we just click the OK button and away it goes. Or we just click it into a schedule. Which can be fine tuned right then and there, no need for other screeens. And associated with alert emails or pagers, should it fail for some reason. All right there.


Yes, it includes all the options for the equivalents of mirrored dbs, ASM, dataguard AND replication as well! In other words, I don't have to wade through half a dozen disjoint screens and 14 manuals in order to be able to handle ALL that possibly relates to the subject of backups!



Or - and this is the REAL corker! - if I'm still a command line afficionado, I can then click the dialogue box title button and bang!: up comes the script to do exactly the same in the command line! All options toggled in the gui, ALL OF THEM, including any necessary scripted and/or coded cross-checks, all written down for me to keep as a project, a script, a history, a teaching material!



Oh, and to get this fine UI, all I have to do is double click on an icon in the desktop. I don't need to start a web server on a cryptic port and a java-based agent residing in "/whatever/get/the/heck/out/of/1.2.4/my/life/blahrkljkajsdkf.jsp - but just for this particular version, because for the next one we'll change the whole directory structure again just to derail your knowledge!"



How come I didn't know all that, you say? Oh, you mean I didn't have time to read the umpteen install guides and release notes? Tsktsk, a dba that doesn't have time to read all day, where has that ever been seen? One would think you'd have to take care of >200 databases, no?



Well, yes: I DO have to take care of >200 databases, thank you very much! And their users and their user's managers! I simply do NOT have time to read 100 manuals for every new point release of your software, mr Oracle!


Sorry folks, but there is simply NO COMPARISON!


The Oracle marketeers look surprised when I tell them the "web-based paradigm" is nothing but disguised complexity.
You see, they are constantly watching "well oiled" presentations. Of course that feels like "easy"!


As someone I know used to say:

"Oracle's software runs perfectly!
And is easy to use!
In Powerpoint..."


But there is more. Much more, folks. I'll continue soon with part 2, where I'll look at the average day-to-day tasks of a SSr9 dba in a typical mixed supplier site.