4 ms·

Somehow - sql server and - reliable don't really belong in the same sentence.

• ghshephard 14y ago
  Do you have any citations or information to indicate that? My understanding from the sqlserver DBAs that I know that the platform is rock solid. Have you heard otherwise? Genuinely interested.
  • Toshio 14y ago
    I've seen several sql server shops with severe performance problems where the in-house DBAs had no clue what had hit them. Different DB engines deal with multi-version read consistency in different ways, Postgres does a defensive copy-on-update, Oracle falls back on rollback segments; unfortunately sql server escalates page locks to table-wide locks, and then performance goes downhill from there. If your friends don't experience any problems, I would venture to guess they must be running small databases, or databases where the workload is 90% reads 10% writes.
    • kogir 14y ago
      Having actually deployed and used SQL Server extensively, I know how it handles "multi-version read consistency": As I tell it to: http://msdn.microsoft.com/en-us/library/ms173763.aspx http://msdn.microsoft.com/en-us/library/ms173763.aspx In addition to setting a database level default, you can even have it behave differently per connection. Snapshot isolation will never lock, period. SQL Server is actually quite capable, and has the fantastic tooling that cheaper alternatives like PostgreSQL lack.
      • Toshio 14y ago
        Care to say how big your database is, and what your workload looks like (reads vs. writes)?
  • EwanToo 14y ago
    SQL Server 2008 and upwards are incredibly solid, we use it extensive at my current work place doing telecoms stuff and have very few issues. It's not what I would have picked (I come from a Linux and Oracle background), but I've been very impressed.
    • ams6110 14y ago
      Agree. TSQL is painful compared to pl/sql. But SQL Server has always been solid in my experience. That may be because it came from outside Microsoft (Sybase) but by now I'm not sure how much of the original implementation is still in the product.
    • Toshio 14y ago
      Care to say how big your database is, and what your workload looks like (reads vs. writes)?
    • EwanToo 14y ago
      Toshio, your comment below is [dead] so I can't reply, but the databases vary from 10's of GB to multi-TB depending on their use. The DBs are often very write intensive on the master, with as much reading as possible done on slave databases, with tables heavily normalised to try and reduce the disk performance hit. Most of the extremes of the setup are there for legacy performance reasons - The newer systems using SQL Server 2008 or 2012 and SSD drives generally don't need it, and we're moving towards a less normalised setup.
      • Toshio 14y ago
        EwanToo, that is very interesting. Also, since the entire discussion started by me questioning the reliability of sql server, can you say how many days your database server stays up between reboots?
        • EwanToo 14y ago
          It would certainly be months or years, depending on patches really rather than an outage.
  • ucee054 14y ago
    SQL Server seems maybe too focused on usability. Oracle's query interpreter, for example, is extremely anal, you have to commit everything and Oracle is likely to reject your queries if they are slightly off, which helps catch errors. SQL Server follows more of a "Do What I Mean" approach, even going as far as to perform implicit type conversions for you, which is fine until it guesses wrong. Then, instead of rejecting your query, it screws up your data. And don't tell me I can configure it to behave differently, it should work correctly out-of-the-box.
• deleted 14y ago
  [deleted]