Re: Snapshot Logfile

From: Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl>
Date: Mon, 29 Aug 2005 21:31:01 +0200
Message-Id: <1125343861.19288.183.camel@dbalert199.dbalert.nl>

Hi Paul,

Your solution is definitely a good step forward in ruling out role-specific namings in directories/SIDs/DB-names. I prefer not to use the %_file_name_convert parameters. As you wrote, it adds (some/a little) complexity to the setup. I personally prefer a symmetric setup.

I can imagine though that a setup according to your suggestion works out in some situations. IMHO, however, a symmetric setup is less error-prone, and more intuitive to me. The fact that I do not prefer it, doesn't mean it is wrong though! I think we are getting close to a matter of 'taste', in stead of 'good or wrong'.

It depends on the people involved, and the situation in the company. When both sites are managed by 1 or 2 DBA's, and maybe at a distance of 30 KM, (or less than 1 KM!), even EAST and WEST doesn't mean that much. Talking USA, east and west coast, and staff involved that might have never met each other is different.

The thing is, when I work in a symmetric setup, I don't have to care about anything in directory structures. I can use simple copy commands like 'scp -pr * otherhost:`pwd`', which will simply send everything from this directory to the equivalennt at the otherhost. I can even share (most of) my parameterfiles among both instances.

I don't use SPFILEs. I use 5 files in a OFA 'pfile' dir:

generic_<SID>.ora  - contains all parameters equal for each role
primary_<SID>.ora  - contains all primary-role specific parameters     
standby_<SID>.ora - contains all standby-role specific parameters

init<SID>_p.ora - contains IFILE= lines for generic and primary init<SID>_s.ora - contains IFILE= lines for generic and standby

The init<SID>.ora no longer exists, neither the symlink in $ORACLE_HOME/dbs. So, it is impossible to start the database without a pfile= option. The DBA has either to script the thing, or think what role he wants to activate. The script-set I implement at my customers' sites takes care of it all, of course.

The generic_<SID>.ora is identical on all sites, and can be copied to all sites easily after a change. The primary and standby files have some site-specific parameters, and cannot be replicated. No need to tell that this works very well in commandline based teams extremely well, and probably not as well at GUI-based sites.

When the server that hosts the standby hosts another database in a primary role (to make the costs of an 'idle' server more acceptable), one can move memory sizing parameters from the generic to the role-specific files, using different sizing depending on the role.

Not very much a strong advice in favor of or against your suggestion, but merely a soft opinion this time, however still hoping it helps,

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===

On Mon, 2005-08-29 at 13:14 -0400, Paul Drake wrote:

> On 8/28/05, Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl> 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
>

--
http://www.freelists.org/webpage/oracle-l

Received on Mon Aug 29 2005 - 14:25:52 CDT