Comments on: Multiplexed redo logs and archiving by default? http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/ Oracle related rants (and lots of off-topic stuff)... Sun, 07 Sep 2008 13:21:15 +0000 http://wordpress.org/?v=2.6.1 By: Tim... http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93246 Tim... Sat, 03 May 2008 08:04:26 +0000 http://www.oracle-base.com/blog/?p=558#comment-93246 I can see a nned for a production system running on a free DB, like mySQL ot XE. Even in these cases, I would hope the database is recoverable. The problem I see is when it fails, people won't say it failed because they made a mistake. They will say it failed because Oracle is rubbish. The same way they used to say Oracle performs badly when they had no stats. I see the introduction of these features as a way of protecting their reputation as much as anything. Cheers Tim... I can see a nned for a production system running on a free DB, like mySQL ot XE. Even in these cases, I would hope the database is recoverable.

The problem I see is when it fails, people won’t say it failed because they made a mistake. They will say it failed because Oracle is rubbish. The same way they used to say Oracle performs badly when they had no stats.

I see the introduction of these features as a way of protecting their reputation as much as anything.

Cheers

Tim…

]]> By: joel garry http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93214 joel garry Fri, 02 May 2008 22:57:04 +0000 http://www.oracle-base.com/blog/?p=558#comment-93214 I just had a requirement for a flat file at a remote site, or else ODBC connection to the production system. So I went, "hey, why don't I give them XE, push the data over there, and they won't have too much problem when their flaky network link dies." I was glad to see archiving was off for the default, I think it is only relevant for a properly designed transactional system, not one with no real DBA around and no need for recovery. How many of those are there with XE, really? Weren't they thinking of not even allowing transactional recovery with XE for a while? http://forums.oracle.com/forums/thread.jspa?messageID=1106793& Maybe the install needs to ask "is this a toy database or a professional database?" :-) I just had a requirement for a flat file at a remote site, or else ODBC connection to the production system. So I went, “hey, why don’t I give them XE, push the data over there, and they won’t have too much problem when their flaky network link dies.”

I was glad to see archiving was off for the default, I think it is only relevant for a properly designed transactional system, not one with no real DBA around and no need for recovery. How many of those are there with XE, really? Weren’t they thinking of not even allowing transactional recovery with XE for a while? http://forums.oracle.com/forums/thread.jspa?messageID=1106793&

Maybe the install needs to ask “is this a toy database or a professional database?” :-)

]]> By: Gary http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93140 Gary Thu, 01 May 2008 23:17:05 +0000 http://www.oracle-base.com/blog/?p=558#comment-93140 While they are at it, why not make Standard Edition the default for an install (or neither, and force the person to decide). An Enterprise Edition user is more likely to be experienced and know when not to pick the default. And it is easier to push a Standard Edition Db to Enterpise Edition than the other way around. I'd suspect there are more Standard Edition installs than Enterprise anyway. While they are at it, why not make Standard Edition the default for an install (or neither, and force the person to decide).
An Enterprise Edition user is more likely to be experienced and know when not to pick the default. And it is easier to push a Standard Edition Db to Enterpise Edition than the other way around.
I’d suspect there are more Standard Edition installs than Enterprise anyway.

]]> By: Tim... http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93110 Tim... Thu, 01 May 2008 12:07:14 +0000 http://www.oracle-base.com/blog/?p=558#comment-93110 I don't think you need to force a backup scenario. They will soon know there is a problem when the flash recovery area fills up, which is a better problem to have than having a lost database. Also, this will force people to read up on how they should be doing backups. I'm not suggesting Oracle can make everything perfectly safe, but they can nudge people in the correct direction. Forcing people into a backup scenario seems too extreme to me. It's something that needs consideration. Cheers Tim... I don’t think you need to force a backup scenario. They will soon know there is a problem when the flash recovery area fills up, which is a better problem to have than having a lost database.

Also, this will force people to read up on how they should be doing backups.

I’m not suggesting Oracle can make everything perfectly safe, but they can nudge people in the correct direction. Forcing people into a backup scenario seems too extreme to me. It’s something that needs consideration.

Cheers

Tim…

]]> By: Fernando Andrade http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93105 Fernando Andrade Thu, 01 May 2008 11:08:33 +0000 http://www.oracle-base.com/blog/?p=558#comment-93105 In that case a default backup job ready to run also is needed, if not the FRA can put the archives as available space. That´s one issue of the idea, if you made the backup as a copy with incremental block apply or as backupset. The option one asumes you have/need more space for you´re FRA, the second one use less space but is not recommended buckup method for Oracle 10g. In that case a default backup job ready to run also is needed, if not the FRA can put the archives as available space. That´s one issue of the idea, if you made the backup as a copy with incremental block apply or as backupset. The option one asumes you have/need more space for you´re FRA, the second one use less space but is not recommended buckup method for Oracle 10g.

]]> By: Tim... http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93092 Tim... Thu, 01 May 2008 07:50:12 +0000 http://www.oracle-base.com/blog/?p=558#comment-93092 Certainly, if the disk fails you lose everything. This is why nobody should run any production system on a server without disk redundancy. As I said in my previous post, it is always possible that a file can get corrupted or lost, so having two copies is safer, even on a single disk system. If you accidentally delete the disk, you still have the other copy. If you get a corrupt file, you will have the other copy. Of course, if you don't care about your database and your happy to lose it, by all means don't multiplex your redo logs and don't use archivelog mode. :) Cheers Tim... Certainly, if the disk fails you lose everything. This is why nobody should run any production system on a server without disk redundancy.

As I said in my previous post, it is always possible that a file can get corrupted or lost, so having two copies is safer, even on a single disk system. If you accidentally delete the disk, you still have the other copy. If you get a corrupt file, you will have the other copy.

Of course, if you don’t care about your database and your happy to lose it, by all means don’t multiplex your redo logs and don’t use archivelog mode. :)

Cheers

Tim…

]]> By: Steeve Bisson http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93062 Steeve Bisson Wed, 30 Apr 2008 22:19:26 +0000 http://www.oracle-base.com/blog/?p=558#comment-93062 I can see why duplexing redo logs is required if you have multiple disks and multiple raid controllers. But if you only have one disk and you duplex them on the same disk, what problem you avoid in that case? If the disk fails, you lose both members anyway. Is it possible that a redo log member can get corrupt and not the other one if both member reside on the same disk? I can see why duplexing redo logs is required if you have multiple disks and multiple raid controllers. But if you only have one disk and you duplex them on the same disk, what problem you avoid in that case? If the disk fails, you lose both members anyway. Is it possible that a redo log member can get corrupt and not the other one if both member reside on the same disk?

]]> By: Tim... http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93052 Tim... Wed, 30 Apr 2008 21:37:54 +0000 http://www.oracle-base.com/blog/?p=558#comment-93052 Hi. You should always multiplex redo logs. Delete one member of a redo log then ask me if it is possible to have a problem with one member of a group on a single disk. :) Cheers Tim... Hi.

You should always multiplex redo logs. Delete one member of a redo log then ask me if it is possible to have a problem with one member of a group on a single disk. :)

Cheers

Tim…

]]> By: Steeve Bisson http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93040 Steeve Bisson Wed, 30 Apr 2008 20:18:48 +0000 http://www.oracle-base.com/blog/?p=558#comment-93040 What happen to simple Oracle Installation on one single disk? Do you still want to duplex your redo logs if you have only a single disk? I admit this must be very very unusual. But is it possible to have one redo log member to be corrupt and the other log member to be perfectly fine in that particular scenario where you have 1 single disk? What happen to simple Oracle Installation on one single disk? Do you still want to duplex your redo logs if you have only a single disk?
I admit this must be very very unusual.
But is it possible to have one redo log member to be corrupt and the other log member to be perfectly fine in that particular scenario where you have 1 single disk?

]]> By: Andy C http://www.oracle-base.com/blog/2008/04/30/multiplexed-redo-logs-and-archiving-by-default/#comment-93031 Andy C Wed, 30 Apr 2008 17:29:10 +0000 http://www.oracle-base.com/blog/?p=558#comment-93031 Love the new theme. I think Scott Wallick's themes for WordPress are simply brilliant. Love the new theme. I think Scott Wallick’s themes for WordPress are simply brilliant.

]]>