Rman and Windows

Thought I would point out a nice little utility i've used on windows 2003 environments. The program is called linkd and it is part of the Windows Server 2003 Resource Kit. Linkd is a utility which allows you to create Junction points on a windows server. Junction point is just the term used for directory symbolic links.

Why is this handy? Recently I was asked to restore a windows production database on a test server. As you may know with rman, it is very picky on paths. For example, if you place your backup in a directory called d:\backup\nightly and would like to restore this on another server, then you have to place the backup in the same path.

Unfortunately there wasn't enough free space on D: for me to place the backup. However, there was more than enough on the H: drive. I used the linkd utility to create a symbolic link from D:\backup\nightly to H:\backup\nightly (can be any path) and ran the restore.

On unix symbolic links are common knowledge, not the same for windows... In this case I took over from a couple of dba's who were trying to get this working for over a day (24hrs straight). They opened a case with Oracle Support and before I took it over they were trying to extract the datafiles manually from the backup. Yikes, painful. So hopefully this tool will become more well known.

Related links:

How to create and manipulate NTFS junction points - MS Support Site
Junction V1.05 - MS Technet
Windows 2003 Resource Kit download page

Training

Good news and bad news. The good news is that I have finally received approval to go on the 11i System Administrator Fundamentals Ed 3 course from Oracle. This will be my first bit of formal training on EBS. I'm sure it will provide me with some useful information and hopefully some interesting posts. The bad news is that Tom Kyte will be in town that week for a half day session on 11g. This course will be taking place in Toronto towards the end of Sept.

Cloning and your SGA

Finally back from a little vacation... It started off rocky. During a normal disk resize operation (SAN attached) the storage team encountered a bug (or feature depending how you look at it) and it corrupted all of the databases on our dev server. Normally this isn't a big deal but we have some rather large projects ongoing at the moment and their environments are also on this server. So, the first weekend of my vacation was spent recovering.
----
Cloning is the act of creating an identical copy of an EBS environment. That means everything from the number of httpd servers to the size of your SGA will be the same. This can be a problem if your cloning from production, since its memory footprint is probably significantly larger than your dev/test environments can support. Whether thats because the server(s) aren't physically large enough or because multiple environments are eating into the available memory. So during the cloning process, you may want to resize the database's SGA.

Note: There are probably a few ways to change the SGA size during cloning. So if you know if another method please leave a comment because i'd be interested in knowing. For the sake of this article, lets assume the only parameter I want to change is the sga_target.

Before you clone an environment you have to prepare the source system by running adpreclone.sh on both the appsTier and the dbTier. This process gathers information about your environment and creates template files. In the case of the database tier, these templates are stored under $ORACLE_HOME/appsutil/template. Two files in particular are:

$ORACLE_HOME/appsutil/template/afinit_db920.ora -- 9i Database
$ORACLE_HOME/appsutil/template/afinit_db102.ora -- 10G Database

If you look at your log file ($ORACLE_HOME/appsutil/log/ApplyDBTier*.log) created during the database post cloning ($ORACLE_HOME/appsutil/clone/bin/adcfgclone.pl ) you will see the below:

instantiate file:
source : /envision1/app/oradb/1020_64bit/appsutil/template/afinit_db102.ora
dest : /envision1/app/oradb/1020_64bit/dbs/initORA.ora
backup : /envision1/app/oradb/1020_64bit/dbs/initORA.ora to /envision1/app/oradb/1020_64bit/appsutil/out/ORA_myserver/0
6220730/initORA.ora

In this case I have a 10g database, so the afinit_db102.ora file is being referenced to create the new parameter file. If you view this file it looks like a normal parameter file except for the fact not all the values are specified. For example:

sga_target = %s_db_sga_target% # Required 11i setting

So one way to modify SGA parameters would be to edit the template file for your database version and hard code the value you want, ie:

sga_target = 700M

Another option would be to modify the context file that is used, in conjunction with the template file, to build the parameter file. I'm not 100% sure that the file i'm about to reference is the correct one but from my limited testing it has worked for me. During the preclone, along with the template file creation I noticed some other files are created. One such being:

$ORACLE_HOME/appsutil/clone/context/db/CTXORIG.xml

Changing the following line in this file from:

<sga_target oa_var="s_db_sga_target">800M</sga_target>

to
<sga_target oa_var="s_db_sga_target">600M</sga_target>


also produces the same result. Once adcfgclone.pl completes the SGA_TARGET in the newly created parameter file will be set to 600M.