Sql-server – SQL Server: Should the same log records be backed up multiple times

No, you still need archived redo logs. An RMAN backup is not the same as a cold backup; when you restore it you need to apply all the redo generated from the time you started the backup until the time the backup completed in order to get the SCN consistent across all the datafiles and the controlfile.

Let us consider the old fashioned hot backup. In this mode, entire changed database blocks are written to the redo log stream, and the file is copied in the OS. This causes fractured blocks, i.e. the block has changed during the read by the backup. So to recover the database, we restore the DBFs, then the recovery process overlays the changed blocks from the archived redo logs onto the fractured blocks in the file, and we get back to a consistent database.

In an RMAN backup the problem of fractured blocks is eliminated because the blocks are read by Oracle via the SGA not by a Unix tool like cp. However the DBF changes between the time the first block is read and the last block, so it is the same problem, just at a larger scale. That is to say, the SCN changes between the first and last blocks in a backup. The archived redo logs cover this as well.

RMAN gives you the manageability of the catalog, and a means to do hot backups without needing to generate redo at a much higher rate (which puts its own stress on the disks, the backup system etc). However BACKUP DATABASE will not give you a consistent database in and of itself; the only way to do that in Oracle is the cold backup.

Seeing that the recovery model is set to simple and msdn states that the simple recovery model does not support point-in-time recovery - Does this mean that I won't be able to use my transaction log backups to restore the database in a disaster to an hour before it happened?

Even taking a transaction log backup is not supported for databases using the SIMPLE recovery model. This is a restriction of the database engine based on how this recovery model works, and the recovery features it doesn't support, as you mentioned.

A transaction log backup maintenance plan task automatically skips databases in SIMPLE recovery to avoid causing errors.

Which backup should be done first, the database backup or the transaction log backups? Articles that I'm busy reading say I should do the database backup first and then the transaction log backup else I will get maintenance plan errors, but I'm currently first backing up my transaction logs and then data databases and I'm not getting any errors.

For the reasons I mentioned above, it won't matter for databases using SIMPLE recovery, as they will be skipped by the transaction log backup task.

For databases in the other two recovery models, a full backup must exist before you start taking transaction log backups (just the first time), or you will get an error -- this is probably what the articles refer to.

Point-in-time recovery ability is normally driven by business need -- in other words, you determine how critical the data is and how much you can afford to lose, then set the appropriate recovery model to meet those needs, and finally create a backup solution.

Even though SIMPLE recovery does not support point-in-time recovery, if an hour of data loss is okay, perhaps a differential backup solution could work for you. (There are far too many variables that go into developing this kind of solution to give you a complete picture with what was provided in the question.)