Some interesting thoughts on SQL Server

  • Recently I was talking to an Oracle DBA and I was telling him about some of the architecture features of SQL Server when he put up some interesting points where Oracle is much better organised than SQL.Here are couple of points which might give you something to ponder at:

    1.In Oracle its a fairly straightforward and regular task to do page-level restores,wheras in SQL such page-level restores are done only when the page is corrupt and its not a straightforward affair.MS needs to have this facility enhanced and better documented so that it can also be done easily for tasks like eg: restoring a table which spans 3-4 pages(besides have the filegroup backup features).

    2.In oracle,one installs the Oracle server and binaries only once.Any further instances on this box can be configured directly from the installed binaries by way of the concept of shared objects.So having 4 different instances for same box dosent consume as much space as 4 SQL instances would consume and dosent require so much of time and effort SQL DBAs need to go through to get this done 4 times.I think MS needs to make some improvements in this regard in its future versions.

    Plz provide yr thoughts and opinions.

    Thank you.

  • As far as your number 2. observation, if Oracle is capable of having multiple instances that are different versions then they may not be able to share anything in the way of installed binaries.

    It is certainly possible to have several Windows services installed using the exact same executable path. However, if you ever wanted to update one of them you would have to stop all services that are executing from that binary file then restart them. Same thing for any DLLs. .Net Assemblies don't have that issue because they are so flexible with regard to version control.

    There is an awful lot of configuring (registry, AD, various folders & files) that happens to make SQL Server run as it does in a client server environment and so tightly integrated into the operating system. This is mostly probably beyond the scope of a simple script and thus, the separate installation requirement.

    The probability of survival is inversely proportional to the angle of arrival.

  • I agree with you.The entire SQL Server design is very OS-specific and this seems to have been more intentional and motivated by business purposes rather than optimization.

  • Ankur Bajaj (9/24/2009)


    I agree with you.The entire SQL Server design is very OS-specific and this seems to have been more intentional and motivated by business purposes rather than optimization.

    I am not sure how you get to this conclusion at all. The fact that it is so closely integrated is in order to give it abilitites other applications don't get (like - memory management, resource management, tracking of many things such as those metrics in perfmon).

    The very large majority of those registry settings, etc... are managed in the installation process for you, so you're not spending days hacking the registry. Now - you CAN spend days tweaking things to get everything "just right" for your environment, but that's true on BOTH platforms, so I'm not sure how either one is a clear winner in this case.

    It's also a stretch to say that because one DB platform decided to go in one direction, and another went in a different direction, that one or the other is wrong/flawed, with no justification why one branch is better than the other.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • I agree that its not right to say that Oracle is better than SQL.

    However what I was trying to say is that SQL architecture is so interpolated with the Windows architecture that if there needs to be an architectual/design change in SQL Server then the underlying OS architecture also has to change.Simple example is that before Windows Server 2003 was introduced,SQL Servers running on 2000 were restricted in their use of AWE.I am sure you would know of many such limitations of SQL wrt Windows 2003 vs 2000.

    What would you prefer to design today..a software which can run only on one OS or one which can run on various different OS like Linux,Unix,Windows which is the case with Oracle.

    If having the facility to install Oracle server on windows OS does not limit its utility or performance then what is the reason Microsoft does not allow(or have the capability for) SQL Server to be installed on non-Windows OS other than business reasons?

  • Ankur Bajaj (9/24/2009)

    ...

    If having the facility to install Oracle server on windows OS does not limit its utility or performance then what is the reason Microsoft does not allow(or have the capability for) SQL Server to be installed on non-Windows OS other than business reasons?

    Everything is a business reason for both Oracle and Microsoft.

    One explanation might be that SQL Server can be half the price of Oracle because it doesn't have to support many different OS platforms.

    You could ask why Microsoft includes Analysis Services with SQL Server, and OLAP is an expensive extra product from Oracle.

    Each product has its strengths and weaknesses.

  • Insofar as multiple instances running on the same binaries, I have to ask "why bother?"

    The only reason I can think of to have multiple instances of SQL Server on the same instance of Windows would be security (or other) isolation. The moment you make them use the same binaries, you reduce that isolation.

    Considering how rarely I've had to do page level restores (never in nearly 9 years as a DBA), I can't say that's a high priority to me. Maybe others have had more experience with needing that.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Michael Valentine Jones (9/24/2009)


    Ankur Bajaj (9/24/2009)

    ...

    If having the facility to install Oracle server on windows OS does not limit its utility or performance then what is the reason Microsoft does not allow(or have the capability for) SQL Server to be installed on non-Windows OS other than business reasons?

    Everything is a business reason for both Oracle and Microsoft.

    One explanation might be that SQL Server can be half the price of Oracle because it doesn't have to support many different OS platforms.

    Agreed. I also can't help but think that the "focus" this creates on the dev team allows them to focus on wringing every bit of capability out of the server OS it happens to run on. Portability is cute and all, but it almost invariably comes at great cost to performance, something that should not be acceptable in your Enterprise server apps.

    Try using 100% portable SQL code, and you will see what I mean.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Suggest you talk to the Oracle DBA & get some real stuff that Oracle does & SQL doesn't. Both of the things you mentioned hardly matter.

  • Oracle has sequences and SQL has identity columns - I curse the person who designed identity columns.

    Oracle does not let reads block writes or writes block reads. This is, without a doubt, the biggest difference between the two DBMS.

    I administer both, slightly preferring Oracle although it is harder work.

    Oracle does use one set of binaries for every instance of the same version. This is useful but not really a reason to buy one or the other. You can install various oracle version on one machine and have instances pointing at one or the other. It's more logical but again who cares.

    My favorite oracle features is the analytic SQL statements like lead and lag. i think that SQL server has something a bit similar but less sophisticated. These functions allow you to look at other rows in the resulyt set so that you can determine things like time between two timestamped rows.

    Platforms is an obvious difference. Because SQL Server only runs on Windows it could be said that it's not a DBMS just DBMS functionality for windows. It's a slightly pedantic view but valid in some ways.

    I may think of some more differences overnight

  • How do sequences work in Oracle?

    You can set up 'Snapshot Isolation' Level in SQL to have readers not block writers & writers not block readers.

  • people keep mentioning 'instances' of oracle and SQL but are we comparing apples to apples here?

    An instance of oracle is just another database, an instance of SQL is a whole new installation capable of supporting multiple databases.

    or has that changed in oracle?

    ---------------------------------------------------------------------

  • An instance of Oracle, while sharing the binaries, has a whole separate dictionary (catalog) and a separate set of tasks In windows. It can be started and stopped independently of any other instance. Each one has its own network address. It's true that there is not a one-to-one relationship between objects of the same type; the poster is correct in saying that we are not comparing apples with apples. A database in SQL Server is similar to a schema in Oracle. It's just a grouping of objects under a high level qualifier.

    Sequences are a simple object that allow your sql to get (or just look at) the next number in a sequence. They are used mostly like an identity column but can do a whole lot more. They can increase or decrease in steps of 1 or more, they can cycle or be random; the best thing is that they are standalone and have nothing to do with the table. I've had lots of problems with identity columns especially with replication.

    I did not know about Snapshot Isolation. I'll have to look at that. My SQL server databases don't really need it so I've never investigated. Thanks for the info.

  • It is easy to take a feature present in one DBMS that does not exist in another and say that the first is the better system. All of the major DBMSs have features that are not present in their competitors, which allows all the vendors to say theirs is the best.

    If your business depends on that particular feature, then the first DBMS is indeed the best. On the other hand, if it is just a feature you might use but have other choices to achieve the business objective, then it is harder to say what is the best.

    Ultimately the best system to have is the one that meets your business objectives and SLAs with the lowest cost of ownership. It all depends on your own unique business objectives, SLAs and ownership costs.

    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

  • It's true that you need the most efficient tool to do the job at hand and the total cost of ownership is one of the considerations. There are also many other things to consider when choosing a DBMS. If your users are like mine, then they change their minds frequently so you must consider the flexibility of the product to meet their needs. Although this is more important in database design than in choice of DBMS. There is also the availability of skills to create and maintain the systems and on this point I think that SQL Server wins. It's easier to train somebody with windows experience to mainatin SQL Server.

    The only reason I use SQL Server is bacuse the client has other SQL server databases and the skills to install and administer from a system point of view. They did not want to get involved in Oracle. Since then they have bough another package which uses Oracle, but there you go.

    If you were to actually sit down and make a rational choice it would be a whole project in itself starting with training courses, experimental systems and a decision making process that would probably need a database and application to support it. Some companies can afford this and I've done it when I worked for a large corporation. The next day, the future arrives and you realise that you would have been better off having made the other choice (also never rule out MySQL).

    It is always more productive to go with what you know because you can start work on day one. But you must always keep an open mind and look at the new versions of competing DBMS systems and write your apps to be portable. We must keep these DBMS people on their toes, don't let them think that we are married to their product lest they become complacent.

Viewing 15 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic. Login to reply