As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
The director of the company I work for met another director of a software company at a party (this is not a joke !).
The second director told my director that,
'he had spent a fortune abandoning SQL Server' because 'if several people were querying the same table in different ways the database locked up'. Further, this is a 'known fundamental design issue with SQL Server where each query competes for maximum resources until SQL Server locks up after about 7 concurrent queries to the same table'.
Now I know a bit about SQL Server locking and IO and this is news to me. AFAIK there is nothing inherent in the SQL Server architectur that causes such problems. And SQL Server performs well in the TPC benchmarks, esp on price/performance.
Feel embarrassed asking but I have to be sure - is there any grain of truth to what he said ?
EDIT - after reading some of the comments I thought Id make it clear that I agree its possible to write poorly performing sql in Sql Server, as it is on any db platform. Sort of asking if there is anyting inherent in the architecture that blocks it out under certain high concurrency conditions irrespective of how well your db/sql is crafted?
There is absolutely no truth to this, and the other director clearly had one of the following two scenarios in his IT department, which can be found at very many firms:
No DBA, or the (idiot) director was the DBA, or someone with no DBA qualifications whatsoever was forced to act as the DBA
An incompetent DBA or incompetent IT employees who created the DB schema(s) and queried the database in incompetent ways given those schemas. Also, see TomTom's comment to this answer below, which expands and expounds on this item further.
Also, do have a look at SQL Server's market dominance at the moment, before coming to any conclusions of its inability to do something.
That is not to say that SQL Server is perfect and has no "fundamental design issues," such as for example this unbelievable bug you can encounter when using identity columns which practically everybody does for surrogate keys:
SCOPE_IDENTITY() sometimes returns incorrect value
I know you can lock up SQL accidentally or with some poorly written queries but I wouldnt say it is a design flaw with SQL Server itself.
I have worked on software that was going to be deployed across the UK, 80+ stores all querying the same tables and never had any problems. Our company also produced way larger software built on a SQL database which would have 100s of stores with anything from 10 - 100+ applications all querying / updating the same tables, we had a few issues with deadlock but they were all resolved.
With the right people and knowledge SQL is an amazing tool, when you get any old programmer and make them the DBA you get problems which I suspect has happened here.
When I hear stories like this unless the person telling me is developing some huge enterprise level application I always think if big business can manage to use this application without it giving them huge problems then me saying I cant use SQL in my smaller application is just me doing it wrong.
It would be interesting to know what they migrated to instead of SQL though.
Poorly written queries can result in the behavior he is talking about. This is not a reason to abandon SQL Server though, it is a reason to look for better developers/DBAs.
Any technology, when used incorrectly can appear to have problems. There are a number of huge projects out there that are built on SQL Server (including StackOverflow). If what he was describing were a result of SQL Server and not the developers then SQL Server would most likely not even be around...
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Currently I have a prototype that runs in IIS on my local machine and uses SQL Server Express 2005 for storing data in three SQL tables. I run queries with transactions that employ up to two of those three tables.
Now I need to move my prototype to Windows Azure and can't decide which to choose - SQL Azure or Azure Table Storage.
How do they compare? How do I decide which to choose?
Windows Azure's SQL Database is a relational database, with all the things you'd expect from a relational database (multiple indexes, stored procedures, powerful queries, etc.). Azure Table Storage is a non-relational, massively scalable (up to 100TB per account) storage facility, where entities are located by partition key (a colocation of entities) and row key.
If you want to have a very simple storage mechanism that doesn't require sophisticated relational operations, Azure Table Storage will work quite nicely.
EDIT June 7, 2012: Updated with Spring Release pricing
There are cost differences too. SQL Database starts at $4.99 for 100MB, scaling up on a tiered scale (about $26 for 5GB, $125 for 50GB, $225 FOR 150GB) but has no transactional costs. Azure Table Storage runs $0.125 / GB (or 0.09 / GB without geo-replication), dropping in per-GB price as quantity goes up, but has a $0.01 / 100,000 transaction cost (nominal for low volume systems, but could be significant with very high volume systems). Full pricing details are here.
There's a fairly recent article in MSDN Magazine that goes into greater detail regarding use cases, differences, etc.
If you're going for a straightforward migration of what you have in place today, SQL Database will closely match what you have in SQL Server Express 2005. However, since it's only a prototype at this point, it's worth re-evaluating your needs.
"How do I decide which to choose?"
Good question.
You have to work out what you care about, and evaluate the options against each other.
The key difference in my view is that SQL Azure is less scalable than table storage. if you're expecting huge numbers of visitors, your database may not be able to keep up, and become the bottleneck that stops you from scaling any further - in the Cloud, you can keep adding front-end servers until your credit card bleeds, but once you've gone to a "big" database server, you have nowhere else to go.
(Except that's not really true - you can also find a way of partitioning your application across multiple database servers).
So, if you care about scalability, you may want to go to table storage - it doesn't have the same scalability limits as SQL Azure.
However, the cost of that scalability is stuff you might also care about - you basically have to architect your application from scratch to work with table storage, and you have to recreate a lot of stuff you get for free from a relational database. Transactions don't really work the way you might expect, for instance.
So, if it's only a prototype, and you're not explicitly intending to become the next Facebook, I'd stay with SQL Azure until the scalability pain becomes real.
i'm just starting out with ms sql server (2008 express) and spent the last hour or so trying out some basic queries. how does sql scripting (correct term?) compare to general computer programming? is writing sql queries as involved, lengthy to learn, needs as much practice, etc. as software development? is writing advanced sql queries comparable to software development, at least to some degree, and if so could you explain that?
also, i found a couple of tutorial and reference sites for learning sql but could you also recommend some other sites.
also(2), i was playing around with the sql query designer in msSQL and it seems like a good tool to learn writing sql commands, but is there a way to use the designer to INSERT data. it seems that it's only for SELECT ing data.
any other general comments for learning, better understanding, etc SQL would be appreciated. thanks
First at all, SQL is more about databases and less about programming, in that way that you you cannot just succeed by "writing good queries": you must also know how to structure your data, make optimized tables, choose appropriate types, etc. You can spend a day thinking about how your data will be stored, without really writing any queries. SQL is not a way to solve an abstract problem, but a way to store and retrieve data efficiently and safely. For example, making maintenance and backup plans is purely a DBA job, and has nothing to do with SQL queries.
Is it lengthy to learn? Well, here, it is quite similar to general development. Basic SQL syntax is pretty simple, so after reading the first page of SQL book, you will probably be able to insert, retrieve and remove data. But to master SQL and database stuff, you must be ready to spend years and years of practice. Just like CSS: writing CSS is easy. Mastering it is hard.
Some advices:
Take in account security.
You communicate with SQL Server by sending strings, and the server must interpret them. The big mistake is to let the end user participate in building your queries: it leads to security leaks, with the ability for the hacker to do whatever he want with your data (it's called SQL Injection). It's just like letting everyone write any source code they want, and execute it on your machine. In practice, nobody let a third person write arbitrary code on her machine, but plenty of developers forget to sanitize user input before querying the database.
Use parametrized queries and stored procedures.
You may want to consider as soon as possible using parametrized queries. It will increase security, optimize performance and force you somehow to write better queries (even if it is debatable).
After learning SQL for a few weeks or months, you may also want to learn what are stored procedures and how to use them. They have their strong points, but don't make an error I made when I started learning SQL: do not decide to use stored procedures everywhere.
Use frameworks.
If you are a .NET developer, learn to use Linq-to-SQL. If you already used Linq on .NET objects (lists, collections, etc.), it can be very helpful to figure out how to do some queries. By the way, remember you can use Linq queries and see how Linq transforms them into SQL queries.
Keep in mind that using a framework or an abstraction layer will not make you a database guru. Use it as a helpful tool, but do sometimes SQL stuff yourself. Yes, it can free you from writing SQL queries by hand, even on large-scale projects (for example, StackOverflow uses Linq-to-SQL). But soon or later, you will either need to work on a project which does not use Linq, or you will see some possible limitations of Linq versus plain SQL.
Borrow a book.
Seriously, if you want to learn stuff, buy or borrow a book. Tutorials will explain you how to do a precise thing, but you will lose an opportunity to learn something you never thought about. For example, database partitioning or mirroring is something you must know if you want to work as a DBA. Any book about databases will talk about partitioning; on the other hand, there are few tutorials which will lead you to this subject by themselves.
Test, evaluate, profile.
SQL is about optimized queries. Anybody can write a select statement, but many people will write it in a non-optimized form.
If you are dealing with a few kilobytes database which have a maximum of hundred records, all your queries will perform well, but when the things will scale up, you will notice that a simple select query spends three seconds on a few billions of rows database instead of a few milliseconds.
To learn how to write optimized queries and create optimized databases, try to work on large sets. AdventureWorks demo database from Microsoft is a good start point, but you may also need sometimes to fill the database with random stuff just to have enough data to measure performance correctly.
Use Microsoft SQL Profiler (included in SQL Server 2008 Enterprise). It will help you to know what the server is really doing and how fast, and to find bottlenecks and poorly-written queries.
Learn from others.
Reading a book is a good point to start, but is not enough. Read the stuff on StackOverflow, especially the questions related to developers doing DBA work. For example, see Database Development Mistakes Made by App Developers question, and return reading the answers from time to time while learning SQL.
If you have any precise question (a query which does not produce what you expected, a strange performance issue, etc.), feel free to ask it on StackOverflow. The community is great, and there are plenty of people who know extremely well the stuff.
Sometimes, talking to DBA in your company (if there is one) can be also an opportunity to learn things.
is there a way to use the designer to INSERT data. it seems that it's only for SELECT ing data
If I remember well, query designed in Visual Studio let you build insert statements too. But maybe I'm wrong. In all cases, you can use Microsoft SQL Management Studio (included with Microsoft SQL 2008 Enterprise), which let you see how to build some cool queries (right-click on an element in Object Explorer, than use "Script database as..." menu).
I think you'll find that they key issue is that SQL is declarative, unlike most computing languages you're likely familiar with. This is fundamental. Grab any computer science text book and start there.
SQL is no more or less difficult than anything else in my view. Historically it was an area which people would tend to specialize in, but that was a consequence of the technology available at the time. It's now more accessible and the tools are significantly better, so expertise is generally spread more widely now.
It is different, SQL programming is quite restricted, when writing complex logic you might find it cumbersome with its limited programming options, unclear code as there is no modular programming, and bad implementations of stuff like cursors.
I read somewhere on SO, that database is not for coding, its only for storing data and querying. Its well said in some sense.
What I believe important to learn in that area is first of knowing all the features available in the db so that you make it use efficiently. Secondly improve querying/analytical skills.
Basic SQL features can be learnt from w3schools(joins , grouping etc)
Advance db features can be learnt from your dbms certification exam book. (the most basic certification exam be it oracle/sql server)
Analytical skills and some fun - puzzles by Joe Celko
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm curious for technical reasons why you choose Oracle database versus the latest flavors of:
1) Microsoft SQL Server
2) MySQL
3) PostgreSQL
What features or functionality justify the extra cost.
I'm interested in technical arguments, not a religious war.
A friend asked me this and I've always used one of the 3 I listed.
I didn't know enough about Oracle Databases to offer an opinion.
Thanks.
Noone seems to talk about the cost of developers time working with Oracle. Most developers who know any other db hate Oracle, those that don't assume that all DB code and/or ORM tools are difficult to use.
If I started a business that I believed was going to scale to Amazon proportions I might consider NoSQL solutions, otherwise I'd choose PostgreSQL, SQL Server (or indeed even Sybase now) over Oracle every time. I say this having worked (as a dev) with Oracle for 2 years - its terrible to work with!
Only Oracle and Microsoft's SQLServer are closed source, and when something goes wrong and you have a problem the answer is just a phone call away (and cash if course). Anyways MySQL and PostGre have several enterprise consulting services but in the end these consultants aren't really resposible for the product, because the product belongs to everyone. Which is great because you can go in and fix the code if you are good with C and relatively lowlevel programming, but if you aren't finding the solution might become a wild goose chase.
Now since not everyone is skilled enough, and those enterprises with money prefer the security (in the business sense) of the closed source databases, is the reason why these solutions haven't gone out of business, besides the fact that their implementations are solid and worth the money if you have it.
Ok now finally the most important difference is between SQLServer and Oracle and that difference is the OS, most people using Windows will stick with, you guessed it, SQLServer, but if you run on flavors of Unix Oracle is your closed source solution. Anyways I use Oracle on Solaris, but if our target were Windows I would probably use SQLServer because both products are rock solid, but I trust Microsoft has some special tricks under the hood to get the best performance on windows.
Just to name a few:
Oracle Real Application Cluster - provides advanced clustering features
Oracle Data Guard - in short provides physical and logical stand-by features.
Oracle Exadata - implements the database aware storage (that can do predicate filtering, column projection filtering, join processing, hastens tablespace creation). The solution comes with HP servers, full 24/7 warranty, and other nice things. It's quite nice for applications with highly intensive data loading (for example thanks to the independent tablespace creation).
Oracle Virtualization
And of course the magic of the brand ;)
And when it comes to choosing the RDBMS? Usually the choice is pretty obvious - Oracle or the rest of the world. After that you can narrow the choice down by:
platform (windows-only or not)
weight (sqlite, MySQL, PostgreSQL, ...)
budget (initial license cost, maintenance + support cost)
evolution perspectives, for example:
Oracle Express -> Oracle
SQL Server Express -> MSSQL
business perspectives - "secure, well known product" or open-source product (bear in mind the quotation around the first phrase). Other post tends to look deeper into this aspect.
The real question is, what kind of application is going to be used to make use of a RDMS. You certainly don't need oracle for your wordpress blog or twitter clone. But if you want to do some heavy business intelligence, then Oracle might have some features which can help doing that more efficiently than the others.
Ms sql server is very good aswell, it has tons of features. If you are struck on linux and you need a database with features as offered by ms sql, then oracle would be a good pick.
I think it's because Oracle was the first RDMS that supported "sharding"
The costs of SQL Server and Oracle are not that far apart, you know.
In fact for small systems the cost of Oracle vs Your Favourite Free Database is between zero (Oracle Express Edition) and not-very-big ($5,800 processor perpetual for Standard Edition One).
Here's a link to the capabilities of the various editions in 11g: http://www.oracle.com/database/product_editions.html.
List prices are available for all territories at http://store.oracle.com -- typically large companies do not pay retail, of course ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In applying for jobs via agents I sometimes get blocked by an agent who says do you know software package X. When I reply that I know the similar package Y they might say unless you know X I cannot put you forward.
The problem is that some of these agents don't know what they talking about, they are merely being used by their clients as a screening filter.
It would be useful to be able to say to these agents that because I know Y I can expect to become reasonably proficient in X in a given number of days/months. However not knowing X determining the required time is why I'm asking this question.
Most recently X was Oracle and Y was SQL Server.
Please can those of you who know both, express an opinion on how long is required to become reasonably proficient? NB I'm not talking about becoming a DBA!
I'll state my bias upfront - Oracle is far more complex than Sql Server. So it depends what you'll be asked to do. You say that this is not for a DBA position but that definition is pretty fluid. At my company, Developers are charged with designing tables, adding the correct indexes, determining partitioning.
If you say, all I'll do is code in java or c# and call packages written by a DBA or Oracle Developer, then you are safe.
But if you take all of your MSSS experience and add semi-colons to the end of your lines you'll kill your Oracle instance. Many standard practices in MSSS are anethema to Oracle. In MSSS it's recommended to have clustered indexes on most every table. In Oracle we build IOTs (Index Organized Tables) only for specific purposes. In MSSS doing DDL in T-SQL is as easy as falling off a log. In Oracle it is made difficult on purpose, it's discouraged and in fact somewhat dangerous. In MSSS you whip off #temp table like they're jelly beans, in Oracle we plan them in advance since they are permanent database objects that aren't just created in the middle of a proc when the logic gets a little tricky.
That said, would you be able to make Oracle do something? Well, yah, but the real question is will it work efficiently and scale to meet the needs of the business your agent placed you at. And that's a resounding no.
I've gone the other way (Oracle first, then SQL Server). My experience is:
SQL queries - trivial differences, except in the realm of string-date conversions, which are WAY easier in Oracle.
Stored Procedures - T-SQL syntax is significantly different from PL/SQL. There is a learning curve there, but nothing insurmountable.
Database Admin - very different, but WAY easier in SQL Server. If that's part of the job description, then they might be justified in considering someone else.
If you're being hired as a DBA, it will take a while to switch between databases as the management of them differs (I base this on my experience with Oracle and DB2 only).
I DON'T know SQL Server but I can imagine a Microsoft program with its nice GUI management would be vastly different to managing DB2/z, for example (although you can use the fancy DB2 LUW (Linux/UNIX/Window) tools if you're that way inclined).
If you're just cutting code to use the database, the SQL differences are minor (relatively). That shouldn't take much time at all, assuming you're already proficient with SQL.
I've done SQL Server for 10 years, but started working with Oracle about a year and a half ago. Like any database, there's no magical proficiency point - you just learn more about it the more you use it. In terms of what a developer would need to know, it shouldn't take more than a week (and even that's a bit much) for an experienced developer to get up to speed with using it. PL/SQL isn't that much different than T-SQL, although stored procs are kind of different.
Programming-wise, the Oracle data access classes are modeled on ADO.NET (we use OleDb actually - one of the side benefits is that you don't have to futz around with the OracleBlob class in order to access BLOB data), so not much learning to be done there.
I originally had my team using TOAD, because I had heard that TOAD is what you're supposed to use with Oracle (although I also heard bad things about it). We eventually got to the point where I was the only one using TOAD, and everyone else was using SqlDeveloper. Avoid TOAD.
I went from SQL Server to Oracle in 2001 where I went from working on a VB6/SQL Server project (as a developer) to working as an Oracle development DBA for a large J2EE project. Here are the edited highlights of my experiences and some reflections.
For development, the basic principle of SQL is not radically differnt. T-SQL is a somewhat different beast to PL/SQL so the idioms are a bit different. Most competent programmers should be able to make the jump by just tinkering around and getting some good SQL server books such as the Guru's Guide or Oracle books such as Expert one-on-one Oracle, depending on which way you're going.
I'd say for a developer a week or two to get used to another database platform will get you most of the way there. The basic principles are fairly similar (modulo differences in the architecture); really only the window dressing is different. However, if you're going to Oracle, get a copy of a third-party query tool such as TOAD as these are much, much, much better than the ones that Oracle supplies.
Agents are notoriously bad for matching specific buzzwords and I get this on a semi-regular basis (I'm a contractor). If you need to bone up on SQL Server the Developer Edition is very cheap and will install on a desktop O/S such as Windows XP. Oracle also offers Free downloads for all their supported platforms that you can use to tinker.
You might also get some mileage from asking a stackoverflow question along the lines of "What are the main idiomatic differences between PL/SQL and T-SQL".
If all you want to do is put a bullet point on your resume to get past the agents, just add it, that will get you past the agents and give you a chance to get your foot in the door. If you are an honest type, grab Oracle XE, Read the appropriate guide at the documentation library, and spend a day or 5 throwing together a blog/address book/flickr clone/etc in your favorite language against Oracle.
As others have suggested there is some significant difference in things you would do compared to SQL Server, if you just apply what you know from SQL Server to Oracle, you'll likely kill performance.
I would disagree that the SQL is similar. The SQL SYNTAX is similar (to the lowest common denominator of ANSI) for basic CRUD development. But actually building packages, writing multi-table / multi step joins, bulk updates and inserts, use of the rich and powerful Oracle feature set is very different from SQL Server. This takes a different mindset and can take many years to master. However...
The purpose of the CV / resume is to get an interview.
Work with your agent to highlight your best TALENTS and BEHAVIOUR'S, not purely skills.
Skill's can be learnt and taught. A talent for, and the demonstration of, learning new skills in new environments is gold dust for an employer.
Don't try to blag it. Don't lie. You'll be found out. Use your experience gained from SQL Server to demonstrate that you can solve the problem. Show eagerness to learn, train and graft.
But, if they really want a "parachute in and start running Oracle programmer", then your stuffed!
AS for my knowledge,It is better to learn Oracle rather than SQL Server because Through out my life I have come across majority of people who are working with SQL Server and a lot competition involved with it because this database is easy to learn.So If you learn oracle,it makes you strong at initial stages and less competition Involved with it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
MS SQL Server and Oracle, which one is better in terms of scalability?
For example, if the data size reach 500 TB etc.
Both Oracle and SQL Server are shared-disk databases so they are constrained by disk bandwidth for queries that table scan over large volumes of data. Products such as Teradata, Netezza or DB/2 Parallel Edition are 'shared nothing' architectures where the database stores horizontal partitions on the individual nodes. This type of architecture gives the best parallel query performance as the local disks on each node are not constrained through a central bottleneck on a SAN.
Shared disk systems (such as Oracle Real Application Clusters or Clustered SQL Server installations still require a shared SAN, which has constrained bandwidth for streaming. On a VLDB this can seriously restrict the table-scanning performance that is possible to achieve. Most data warehouse queries run table or range scans across large blocks of data. If the query will hit more than a few percent of rows a single table scan is often the optimal query plan.
Multiple local direct-attach disk arrays on nodes gives more disk bandwidth.
Having said that I am aware of an Oracle DW shop (a major european telco) that has an oracle based data warehouse that loads 600 GB per day, so the shared disk architecture does not appear to impose unsurmountable limitations.
Between MS-SQL and Oracle there are some differences. IMHO Oracle has better VLDB support than SQL server for the following reasons:
Oracle has native support for bitmap indexes, which are an index structure suitable for high speed data warehouse queries. They essentially do a CPU for I/O tradeoff as they are run-length encoded and use relatively little space. On the other hand, Microsoft claim that Index Intersection is not appreciably slower.
Oracle has better table partitioning facilities than SQL Server. IIRC The table partitioning in SQL Server 2005 can only be done on a single column.
Oracle can be run on somewhat larger hardware than SQL Server, although one can run SQL server on some quite respectably large systems.
Oracle has more mature support for Materialized views and Query rewrite to optimise relational queries. SQL2005 does have some query rewrite capability but it is poorly documented and I haven't seen it used in a production system. However, Microsoft will suggest that you use Analysis Services, which does actually support shared nothing configurations.
Unless you have truly biblical data volumes and are choosing between Oracle and a shared nothing architecture such as Teradata you will probably see little practical difference between Oracle and SQL Server. Particularly since the introduction of SQL2005 the partitioning facilities in SQL Server are viewed as good enough and there are plenty of examples of multi-terabyte systems that have been successfully implemented on it.
When you are talking 500TB, that is (a) big and (b) specialized.
I'd be going to a consultancy firm with appropriate specialists to look at the existing skill sets, integration with existing technology stacks, expected usage, backup/recovery/DR requirements....
In short, it's not the sort of project I'd be heading into based on opinions from stackoverflow. No offence intended, but there's simply too many factors to take into account, a lot of which would be business confidential.
Whether Oracle or MSSQL will scale / perform better is question #15. The data model is the first make-it or break-it item regardless of if you're running Oracle, MSSQL, Informix or anything else. Data model structure, what kind of applicaiton, how it accesses the db etc, which platform your developers know well enough to target for a large system etc are the first questions you should ask yourself.
I've worked as a DBA on Oracle (although some years back) and I use MSSQL extensively now, although not as a formal DBA. My advice would be that in the vast majority of cases both will meet everything you can throw at them and your performance issues will be much more dependent upon database design and deployment than the underlying characteristics of the products, which in both cases are absolutely and utterly solid (MSSQL is the best product that MS makes in many peoples opinion so don't let the usual perception of MS blind you on that).
Myself I would tend towards MSSQL unless your system is going to be very large and truly enterprise level (massive numbers of users, multiple 9's uptime etc.) simply because in my experience Oracle tends to require a higher level of DBA knowledge and maintenance than MSSQL to get the best out of it. Oracle also tends to be more expensive, both for initial deployment and in the cost to hire DBAs for it. OTOH if you are looking at an enterprise system then Oracle would have the edge, not least because if you can afford it their support is second to none.
I have to agree with those who said deisgn was more important.
I've worked with superfast and super slow databases of many different flavors (the absolute worst being an Oracle database, but it wasn't Oracle's fault). Design of the database and how you decide to index it and partition it and query it have far more to do with the scalability than whether the product is from MSSQL Server or Oracle.
I think you may more easily find more Oracle dbas with terrabyte database experience (running a large database is a specialty just like knowing a particular flavor of SQL) but that could depend on your local area.
oracle people will tell you oracle is better, sql server peopele will tell you sql server is better.
i say they scale pretty much the same. use what you know better. you have databases out there that are that size on oracle as well as sql server
When you get to OBSCENE database sizes (where over 1TB is really big enough, and 500TB is frigging massive), then operational support must come very high up on the list of requirements. With that much data, you don't mess about with penny pinching system specifications.
How are you going to backup that size of system? Upgrade the OS and patch the database? Scalability and reliability a concern?
I have experience of both Oracle and MS SQL, and for the really really big systems (users, data or importance) then Oracle is better designed for operational support and data management.
Every tried to backup and restore a 1TB+ SQL Server database split over multiple databases on multiple instances with transaction log files being spat out everywhere by each database and trying to keep it all in sync? Good luck with that.
With Oracle, you have ONE database (so I disagree with the "shared nothing" approach is better) with ONE set of REDO logs(1) and one set of archive logs(2) and you can just add extra hardware nodes without changing (i.e. repartitioning) you application and data.
(1) Redo logs are, of course, mirrored.
(2) Archive logs are, of course, stored in multiple locations.
It would also depend on what is your application meant for. If it uses only Inserts with very few updates, then I think MSSQL would be more scalable and better in terms of performance. However if one has lots of updates, then Oracle would scaleup better
I very much doubt that you are going to get an objective answer to that particular question, until you come across anyone that has implemented the same database (schema, data, etc.) on both platforms.
However given the fact that you can find millions of happy users of both databases, I dare say it's not too much of a stretch to say either will scale just fine (I've seen a snappy Sql 2005 implementation of 300 TB that seemed pretty responsive)
Oracle like a high-quality manual film camera, which needs the best photographer to take the best picture while MS SQL like an automatic digital camera. In old days, of course, all professional photographers will use film camera, now think about how many professional photographers use automatic digital camera.