Re: Snapshot Logfile
- From: Paul Drake <bdbafh@xxxxxxxxx>
- To: cjpengel.dbalert@xxxxxxxxx
- Date: Mon, 29 Aug 2005 13:14:53 -0400
On 8/28/05, Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx> wrote:
>
> Hi Sami,
>
> Yes, that should work. The Rule of thumb form the doc probably should read
> '(max.nr.of log file groups for each thread +1 ) * maximum number of
> threads.'
> but the result will be the same. Alas, I've no DG/RAC experience yet, I
> might be wrong here.
>
> I do not particularly like your direcotroy naming, though. You use a
> directory named 'primary'. This suggests you have a directory 'standby'
> somewhere as well. What if you have to perform a switchover/failover? The
> name of the directory will no longer resemble it's role by then. You will
> have to deal with a confusing setup by then, where compnents of the primary
> actually are named standby and vice versa. This will make you system more
> (human) error prone.
>
> My advice is to keep systems on both ends as symmetric as possible, using
> the same direcory structure and instance/database names at both ends. That
> implies that naming conventions should avoid embedding roles in the names.
> Compare it with 'meaningless keys' in data modeling, which might survive
> longer than meaningfull keys. (I don't want to get that discussion loose
> here, and if it starts I will not contribute)
>
> A meaningfull name of a server, directory, instance or database can and
> will become problematic. One day, it's role will change and the name will
> start confusing you ISO of helping you. And that is something you do not
> want in an environment that is presumed to be highly available!
>
> Best regards,
>
> Carel-Jan Engel
Carel-Jan,
Are you saying that for Dataguard you do not advocate the use of
location-specific subdirectories for file locations, e.g.
<vol>\oradata\%db_name%\%db_unique_name_1%
h:\oracle\oradata\mydb\eastmydb\
h:\oracle\oradata\mydb\westmydb\
in conjunction with the use of:
db_file_name_convert
log_file_name_convert
Although at first it seemed as if it was introducing additional complexity,
it sure does get rid of the idea of primary and standby being hardcoded into
serivce_names and directory structures.
It seemed to me that if someone else would have to take over in the event
that my current location is obliterated ... that including the locations in
the directory structure would make things more intuitively obvious at
crunchtime. This is not to say that documentation and practice runs
shouldn't be performed ... but one never knows who might have to pull the
trigger if say the east coast data center isn't accessible.
thanks,
Paul
Other related posts:
