1. Full DoD “Orange Book” compliance. If you are doing anything that requires real security compliance, Oracle is fully compliant, while SQL Server meets few, if any, of the compliance requirements. Not a big deal if you aren’t worried about security at that level.

2. Ability to use Oracle Packages to encapsulate information with session persistence. This is the biggest single difference I have encountered between Oracle and SQL Server. In Oracle PL/SQL, you can create Packages, which can contain local, session-persistent data structures, plus layers of stored procedures, functions, memory table structures (arrays), user-defined new structured data types, etc. You can essentially build structured business objects with public and private structures and interfaces all within the Oracle PL/SQL environment. There is no equivalent capability in SQL Server - to do something similar requires writing external code, creating temporary tables, and in general, creating much more complex code to solve similar problems. (Yes, you can achieve the same end result, but debugging will be much more complex - you won’t be able to trace and obtain variable information throughout the process, as you can within the Oracle environment.)

3. As noted - ability to run on multiple OS platforms. Not a big deal if you are a Windows shop.

If you don’t need any of the above, then it probably comes down to price.

The biggest factor in favor of SQL Server is price. Both Oracle and SQL Server are available in “free” versions for small or single-user development environments, and for small servers/workgroups the prices are pretty competitive. However, as your server size and/or number of CPUs goes up, the Oracle price goes up quite a bit faster than SQL Server.

One note - for a long time, SQL Server was sold with the claim “it doesn’t require a DBA”. I would put that claim right up there with “the check is in the mail.” Both SQL Server and Oracle require someone with DBA expertise - if Oracle seems to require more DBA expertise, that is because it offers a LOT more opportunities to fine-tune a large implementation. For smaller implementations, the amount of DBA activity and knowledge required for either product is similar.