Archive for November, 2008
TOD – Coming in from the cold – Bringing datafiles into ASM
Posted by Jay Caviness in ASM, Tip 'o the day on November 19th, 2008
I received a panicked call the other day from a DBA who had a user create a new datafile on a cooked filesystem. All was not lost and it didn’t require a downtime to fix, however, it did require that tablespace to be taken offline for a time.
In all databases I create using ASM I set the parameter: DB_FILE_CREATE_DEST (and it’s cohort DB_CREATE_ONLINE_LOG_DEST_X, which I will discuss in the future) and set it to the value of the default diskgroup (in our case +DGROUP1). This makes life much easier for a dba as the file parameters are no longer needed:
SQL> create tablespace asm_demo datafile size 20m; Tablespace created. SQL> select file_name from dba_data_files 2 where tablespace_name = 'ASM_DEMO'; FILE_NAME ------------------------------------------------------------ +DGROUP1/qa/datafile/asm_demo.974.671209339
In the above example, if the db_create_file_dest parameter is set, the only information I need to create a tablespace is the tablespace name. Technically, even the size is not needed as a default size of 10m is used if the size is omitted.
This is all well and good, but what happens if someone comes along and creates a file the old fashioned way:
SQL> create tablespace test datafile '/home/oracle/test_01.dbf' 2> size 10m;
How do you get this file into asm? Elementary my dear Watson! First take the tablespace offline.
SQL> alter tablespace test offline;
Start RMAN and backup a copy of the datafile into ASM, since the tablespace is offline, no transactions will change the datafile. (I will leave out the extraneous rman info)
RMAN> backup as copy tablespace 'TEST' format '+DGROUP1';
Tell the data dictionary to use the new copy.
RMAN> switch tablespace 'TEST' to copy;
datafile 50 switched to datafile copy
"+DGROUP1/qa/datafile/test.973.671207181"Finally, bring the tablespace back online, either from rman or sqlplus, and check where the datafile is no located.
SQL> alter tablespace test online; Tablespace altered. SQL> select file_name from dba_data_files 2> where tablespace_name = 'TEST'; FILE_NAME ------------------------------------------------------- +DGROUP1/qa/datafile/test.973.671206913
That is it, now, admittedly taking an active tablespace offline can be a challenge and may require a downtime based on your application. But, the movement of the file into ASM is quite simple. In the end the DBA is happy and the user that created the cooked datafile was educated and given 50 lashes with a wet noodle.
TOD – olsnodes hangs temporarily
Posted by Jay Caviness in RAC, Tip 'o the day, general on November 19th, 2008
In using rac, I have found it handy to modify oraenv to use the olsnodes -n -l command to find the local node number and append it to the database name for the real sid.
/home/oracle:()$ . oraenv ORACLE_SID = [oracle] ? qa /home/oracle:(qa1)$ echo $ORACLE_SID qa1
I find this easier than manually setting the sid as it is consistent on each node. One issue I have run into is that after a node has been around for a while there can be a lag time in using oraenv to set the sid.
Tracing the problem, I found it would hang for several seconds on the olsnodes command. Minor, but annoying, especially when in a hurry. In trying to find the cause I discovered that olsnodes would write a logfile to the $CRS_HOME/log/
The obvious solution is to remove these files, in most cases an “rm” command will not work as the file list is too long so a find command would be used:
find . -name "*.log" -exec rm -f {} \;The best resolution would be to create a cron job that would remove all old logs:
00 03 * * * /usr/bin/find /oracle/product/10.2.0/crs_1/log/lx52/client \( -name "css*.log" -o -name "*.trc" \) -mtime +1 -exec /bin/rm -f {} \;In the example above at 3am we find all the css*.log and *.trc files older than midnight yesterday and remove them. Based on running at 3am, it would remove all files over 27 hours old.
TOD – Installing Oracle fails citing “Not enough space”
Posted by Jay Caviness in Tip 'o the day on November 7th, 2008
I perform a great many installations of Oracle both RAC and non-rac, in fact, I have installed RAC on over 200 clusters now. In the process of this I have created silent install processes to help make a cluster install easier on everyone involved. From time to time, however, the silent install (and sometimes an interactive install) fails with the error “You may not have enough space on your drive for a successful install. Do you still want to continue?” This is all well and good if interactive as you can say yes or no, but in a silent install all is lost and you will have to start over.
But what causes this error? The obvious is not enough space in the filesystem on which you are installing the Oracle software, but not always. Oracle typically espects anywhere from 1.6 to 3.5G free on that filesystem depending on product and platform. You may run into a case where there is plenty of room, so why did it fail? What the error doesn’t tell you is where the installer is looking for that space. It is not only your installation (Oracle_base) filesystem, but also /var and /tmp. If there have been several other installs, successfull or not, Oracle uses /tmp and /var/tmp to store installer information in directories in the format “OraInstallYYYY-MM-DD_HH-MM-SS{AM|PM}. These directories are not automatically removed at the end of installations and not if an install fails. Oracle requires typically about 400M in these filesystems, if not found, it will fail with the error above. So remember to clean out /var/tmp and /tmp after your installations!
Election Day in the US – Get out and Vote!
Posted by Jay Caviness in general on November 4th, 2008
