Re: Non-*.ctl Control File Naming Convention
Date: Tue, 15 Jul 2008 07:57:20 -0700 (PDT)
Message-ID: <53ad3190-4687-4901-8469-e66f22f0b0f9@c65g2000hsa.googlegroups.com>
On Jul 15, 9:44 am, "Joey.Dant..._at_gmail.com" <Joey.Dant..._at_gmail.com>
wrote:
> To all,
>
> I had a vendor tell me yesterday, that it was a good idea to name all
> of your database related files *.dbf, including control files. This
> immediately set off a red flag as it violates OFA. Anyone doing this,
> and if so what is your rationale?
>
> The vendor said it made UNIX find commands easier.?!?
>
> The vendor is a "reputable reinstaller of Oracle", but there were a
> few other comments that made me question there knowledge.
>
> A bit of background is that I just took a new role, and Oracle is
> fairly new to the shop, and they have a large implementation. So they
> had contracted the vendor to do the groundwork, before they hired me.
> At this point it's a bit of an annoyance, as I'd like to just do my
> own thing (well OFAs own thing) architecture wise, and not have to
> deal with the 3rd party.
>
> Thanks
>
> jd
And what exactly is so good about OFA?
The software installation file structure and the database datafile file structure should be separate and distinct from each other.
In the days of manual backup scripts naming all the database datafiles with a .dbf ending probably made some sense; but if you use rman for your backups when do ever have to script the database datafiles anyway? You can query your datafile, control file, and log files names from the database so having .ctl, .dbf, and .log extensions makes sense to me since even if you do need to script them obtaining the names dynamically is not difficult.
It could be a vendor support issue. By using one standard then scripts probided by the vendor will work without changes being required due to difference in how sites name their files. In my opinion the correct solution to this problem for the vendor is to write scripts that generate the scripts to do such tasks as create a manual hot backup, copy files to duplicate the database, etc ....
HTH -- Mark D Powell -- Received on Tue Jul 15 2008 - 09:57:20 CDT