Learned a couple things about bash today. I was wanting to print something out nicely, so I was using tabs to separate fields. As you know, nothing ever lines up if you do not have values very similar in size. So I was about to search Google for the problem when I had a moment of sheer brilliance. I thought I’ll just concatenate a bunch of spaces on the end of the variable and then use cut to grab how many characters I want. I was very proud of myself, but then bash quickly humbled me by condensing all my spaces I had added to the variable.

So, back to the all knowing Google. Turns out you have to quote your variable when you use it if you don’t want bash to truncate the spaces. So I quoted my variable when using it and all is good.

BUFFER="$VAR                                                                "
NICE_VAR=`echo "$VAR" | cut -c -15`
echo "$VAR $VAR2"

The procedure below will allow you to move Oracle data and redo files.

1. It is a good idea to make a backup of the directory you are moving just in case something goes horribly wrong.
# cp -rp {data_dir} {backup_dir}

2. log in as the oracle user
# su -l oracle

3. move the database files
# mv {data_dir} {new_data_dir}

4. Set SID, log into database.
# export ORACLE_SID={ORACLE_SID}
# sqlplus /nolog
SQL> connect /as sysdba;

5. Create pfile from spfile
SQL> create pfile from spfile;

6. In another terminal, modify the newly created pfile. It is usually called init{SID}.ora and can be in different directories. Look in udump, dbs, and other directories until you find the newly created pfile. Check the date to make sure it is the one you are looking for. Now, fix the directories for the control_files variable.

7. Go back to the original terminal and create spfile from pfile;
SQL> create spfile from pfile;

8. Mount database.
SQL> startup mount;

9. Alter the database to look in the new location for the data files and redo logs. Below is an example. (Do this for all data and redo logs.)
SQL> alter database rename file ‘/home/oracle/oradata/{SID}/sysaux01.dbf’ to ‘/usr/local/app/oracle/oradata/{SID}/sysaux01.dbf’
SQL> alter database rename file ‘/home/oracle/oradata/{SID}/redo01.log’ to ‘/usr/local/app/oracle/oradata/{SID}/redo01.log’

10. Open database.
SQL> alter database open;

Now it should hopefully come up properly. You man want to shut it down and bring it up once more to make sure everything is working properly.

Disclaimer: This is plagiarized! See: http://www.anysql.net/en/oracle/oracle_bug_exp00003.html

When you use old version of exp to export tables with LOB column from Oracle 9.2.0.5 or higher version, you will get an error “EXP-00003 : no storage definition found for segment …..”, actually this is an Oracle bug, you could temporary get it resolved by replace a view “exu9tne”, as following:

Before exporting, run the following SQL under sys:
CREATE OR REPLACE VIEW exu9tne (
tsno, fileno, blockno, length) AS
SELECT ts#, segfile#, segblock#, length
FROM sys.uet$
WHERE ext# = 1
UNION ALL
SELECT * FROM SYS.EXU9TNEB
/
After exporting, run the following to restore the view definition according to Metalink Notes.
CREATE OR REPLACE VIEW exu9tne (
tsno, fileno, blockno, length) AS
SELECT ts#, segfile#, segblock#, length
FROM sys.uet$
WHERE ext# = 1
/

When trying to install an older version of the JRE on a newer Linux distro I was getting the following error:

Unpacking...
tail: cannot open `+480' for reading: No such file or directory
Checksumming...
1
The download file appears to be corrupted. Please refer
to the Troubleshooting section of the Installation
Instructions on the download page for more information.
Please do not attempt to install this archive file.


This is because tail has changed in the newer Linux distros. the +{number of lines} does not work unless you proceed it with a -n. So, edit the .bin file you downloaded make the following changes:


Replace: tail +480 $0 > $outname
With: tail -n +480 $0 > $outname
Replace:
if expr $sum1 != 22444 || expr $sum2 != 13542 ; then
echo "The download file appears to be corrupted. Please refer"
echo "to the Troubleshooting section of the Installation"
echo "Instructions on the download page for more information."
echo "Please do not attempt to install this archive file."
exit 1
fi
With:
# if expr $sum1 != 22444 || expr $sum2 != 13542 ; then
# echo "The download file appears to be corrupted. Please refer"
# echo "to the Troubleshooting section of the Installation"
# echo "Instructions on the download page for more information."
# echo "Please do not attempt to install this archive file."
# exit 1
# fi


I usually use phpMyAdmin to dump my table to SQL, but sometimes it is easier to do it from the command line. Use the following syntax to dump a table to SQL.

mysqldump -p -e -c --add-drop-table -r table.sql dbname table

Warning: The –add-drop-table will cause it to drop the existing table when you import.

You can import this with the command

mysql -p dbname < table.sql

Looks like this filesystem has some promise, hope it matures quickly.

http://oss.oracle.com/projects/btrfs/

I was thinking to myself it would be really great if Dell made available a yum repository for open manage. So I did a search and sure enough the do! This makes my job a lot easier

http://linux.dell.com/repo/hardware/

Also check out http://linux.dell.com/wiki/index.php/Repository/software
and http://linux.dell.com/wiki/index.php/Repository/firmware

I was getting errors when trying to download a file from a mounted windows share with vsftpd.  The fix for this problem is to add use_sendfile=NO to your vsftpd.conf file.

When upgrading with yum I have started taking an rpm inventory before and after the upgrade.
Before Upgrade:

rpm -qa > BeforeUpgrade.txt

After Upgrade:

rpm -qa > AfterUpgrade.txt

Then I can compare them so that I know which packages were not upgraded and I can figure out why the did not upgrade.

cat BeforeUpgrade.txt AfterUpgrade.txt | sort | uniq -c | sort -n | grep "^\ *2"

I upgraded a server from CentOS 4 to CentOS 5 via yum and kept getting “Could not find any working storages.” I searched the web and found some other people having the same problem, but I didn’t see any solutions. After some fun with strace, I found that it was looking for /usr/lib/python2.4/site-packages/sqlite which wasn’t there. It turns out that the package name for python-sqlite did not change between CentOS4 and CentOS5 so the package was not upgraded. I suggest that if you have this problem you look at all the files in /usr/lib/python2.3/ and find out what packages they belong to with “rpm -qf” and upgrade them manually. You can upgrade python-sqlite with the following command (The version number may change).

rpm -Uvh --force http://mirror.centos.org/centos/5.1/os/i386/CentOS/python-sqlite-1.1.7-1.2.1.i386.rpm