Two words - "Database Mirroring"... Almost instant stand-by with very fast (~3 seconds) automatic or manual fail over. The client libraries also detect and fail over automatically too. To ensure this happens correctly a third server called the "Witness" provides majority logic to ensure that only a single side is up at any one time. I also get the feeling that Microsoft would prefer you to not attempt to use replication as a fail over solution as there are a number of issues to overcome - data loss, client fail over, recovery and the amount of custom code required to make it work properly. One thing you can't do on a mirror is use it. Kind of obvious really, but you can't even connect in a read-only mode.

Help is at and though - another interesting feature that will be available is a "Database Snapshot" which uses copy on write semantics to provide efficient views of a database at a point in time. A snapshot does not need to copy the database as it will reference the original database pages until they are modified. These snapshots can be created on mirrors which provide ideal access for reporting. Those that have all their data stored in a single database may want to think about splitting it into reporting databases and online databases. Basically, stick the information into a reporting database but keep the OLTP and application runtime data in another.

One last honourable mention is for SNAPHOT ISOLATION LEVEL - similar to Oracle's row versioning. But remember that tempdb is used to store the version information whilst a transaction is in progress.