Database and log files

SQL calls it transaction logs.  Oracle calls it archived logs.  That would be simple backup perspective.  More deeper view is following. Oracle places changed into something called online redo log which is used to replay SQL statements. If your database is not in archive log mode, then this redo files gets eventually rotated and you loose point to which you can recover. This is why redo log gets archived into something that is called archive log and for that your database needs to be in archived log mode. Once redo files fill, they archive content. When doing backups, you can also execute switch before you start archive log backup. Best practice is to have datafiles, redo logs and archive logs on separate volumes.

In SQL, you have so called recovery model which similar to archive log enables you to use or not to use transaction logs (eg. simple recovery model will always produce full database backup if you try to run transaction log backup). Transaction logs also keep a track of changes and enable you as with Oracle PiT recoveries. Unlike redo log concept which can switch, transaction log continue to grow and grow and unless you run the transaction log backup, it will grow and grow.. You may expect that transaction log will be truncate it once transaction log backup is done, but it won't. Instead, the file will get new data inside (internal rotation if you want). To truncate it, you will need to run transaction log backup and shrink it from SQL. As of SQL 2005, MS does not recommend truncate to be used with backup statements. I'm not sure how this exactly is now in SQL 2012 which I heard follows logic of Exchange, but I really didn't touch it yet. In practice, I have seen people keeping SQL logs on separate partitions/disk for multiple databases (same as for datafiles), but in case you plan to use some snapshot technologies you will need to split those.