Re: Problem with installing Oracle

On Nov 8, 8:38 pm, Lodewicus Maas <linux.oracle...._at_googlemail.com> wrote:
> hjr.pyth..._at_gmail.com wrote:
> > On Nov 2, 12:17 am, dbm..._at_gmail.com wrote:
> >> On 1 stu, 12:10, hjr.pyth..._at_gmail.com wrote:
>
> >>> On Nov 1, 9:33 pm, dbm..._at_gmail.com wrote:
> >>>> On 1 stu, 11:26, dbm..._at_gmail.com wrote:
> >>>>> First of all, hello to the group !
> >>>>> I have a problem installing Oracle 10g release 2 on RHEL 4 update 4. :
> >>>>> (
> >>>>> RHEL is fresh installation with next packages:
> >>>>> a.. Server Configuration Tools (4 of 11)
> >>>>> a.. Development Tools (57 of 75)
> >>>>> a.. X Software Development (16 of 18)
> >>>>> a.. Compatibility Arch Development Support (8 of 8)
> >>>>> a.. Legacy Software Development (6 of 6)
> >>>>> a.. Administration Tools (11 of 12)
> >>>>> a.. System Tools (12 of 50)
> >>>>> a.. libaio-0.3.105-2.x86_64.rpm
> >>>>> Next, I've created oracle user that will run the installation and
> >>>>> edited his
> >>>>> profile. Also I have created two groups, oinstall and dba and edited
> >>>>> kernel
> >>>>> parameters.
> >>>>> groupadd dba
> >>>>> groupadd oinstall
> >>>>> useradd -m oracle -g oinstall -G dba
> >>>>> mkdir /oracle
> >>>>> mkdir /oracle/10g
> >>>>> chown -R oracle:oinstall /oracle
> >>>>> mkdir /osource
> >>>>> cat >> /home/oracle/.bash_profile << EOF
> >>>>> #Added for Oracle Installation
> >>>>> ORACLE_BASE=/oracle
> >>>>> ORACLE_HOME=/oracle/10g/db_1
> >>>>> ORACLE_SID=INFAT
> >>>>> export ORACLE_BASE ORACLE_HOME ORACLE_SID
> >>>>> PATH=/oracle/10g/bin:$PATH:.
> >>>>> export PATH
> >>>>> EOF
> >>>>> cat >> /etc/sysctl.conf << EOF
> >>>>> #Added for Oracle Installation
> >>>>> kernel.shmall = 2097152
> >>>>> kernel.shmmax = 2147483648
> >>>>> kernel.shmmni = 4096
> >>>>> kernel.sem = 250 32000 100 128
> >>>>> fs.file-max = 65536
> >>>>> net.ipv4.ip_local_port_range = 1024 65000
> >>>>> net.core.rmem_default = 262144
> >>>>> net.core.wmem_default = 262144
> >>>>> net.core.rmem_max = 262144
> >>>>> net.core.wmem_max = 262144
> >>>>> EOF
> >>>>> Installation itsefl is successfull but when it comes to the linking
> >>>>> part, it
> >>>>> just breaks with errors on next sceenshoots:
> >>>>>http://aycu16.webshots.com/image/31775/2000600490498948133_fs.jpg
> >>>>>http://aycu16.webshots.com/image/30975/2000609142436376501_fs.jpg
> >>>>>http://aycu26.webshots.com/image/33945/2000621709332438227_fs.jpg
> >>>>>http://aycu07.webshots.com/image/31606/2006214369960489243_fs.jpg
> >>>>>http://aycu03.webshots.com/image/33762/2006205106893786925_fs.jpg
> >>>>>http://aycu33.webshots.com/image/34192/2006225690369446577_fs.jpg
> >>>>> Please help !! :((((
> >>>> I fogot to say that RedHat is 64bit and so is Oracle.
> >>> You also forgot to say you're using my guide athttp://www.dizwell.com/prod/node/728
> >>> !!
> >>> Shame you didn't feel able to ask questions about the script on the
> >>> site where you got it. We don't spam, you know: you can part with a
> >>> valid email address and get precisely four emails from us in 3 months!
> >>> Although you've cut-and-pasted most of my rootprep.sh script, you
> >>> don't seem to have done the sysctl -p bit which the original does.
> >>> Presumably, that was just a bit of concision on your part?
> >>> I'd first suspect that your installation wasn't quite the same as
> >>> mine: did your installation size get reported as 4,055MB or not? If
> >>> not, we have a problem. And I suspect I know what it is, because
> >>> you'll get these sorts of error if you're not using the operating
> >>> system I documented to use! That article discussed using Centos 4.4 or
> >>> OEL 4.4 -that is, Update 4 of the fourth version of those OSes. If
> >>> you're using update 1, 2 or 3, you can run into this problem, the fix
> >>> for which is to do an rpm -Uvh glibc-devel-2.3.4-2.9.i386.rpm (yup,
> >>> that's the 32-bit version of the libraries, even on a 64-bit OS). But
> >>> I'd recommend downloading afresh the correct release of the OS, if
> >>> indeed that is the issue.
> >>> Apart from that, and since I know the installation works just fine
> >>> otherwise I'd have documented workarounds for these sorts of issue,
> >>> I'd suspect your installation software next: again, a fresh download
> >>> might be in order. What number of blocks did you get reported when you
> >>> unpacked the cpio? The original article tells you what answer you
> >>> *should* have got.
> >>> Other than the above, I haven't a clue: if you use the same OS as me
> >>> and select the same package groups as me and install the same libaio
> >>> as me, the rules of deterministic software demand that we end up
> >>> achieving the same outcome! I can only re-iterate that I document what
> >>> happens to me, exactly and without missing out minor details like the
> >>> whole thing blowing up!- Sakrij citirani tekst -
> >>> - Prikaži citirani tekst -
> >> Oh I'm so sorry.. :( First of all, I wanna thank you for that guide
> >> of yours ! ;)) Sorry I was being so rude.
>
> >> I have to say that your blog is amazing. You really helped me with
> >> that guide and with many others. ;) I've installed couple of times
> >> Oracle using this guide and your scripts on RHEL 4 and never had any
> >> problems. But never on RedHat 4 update 4 though. :(
>
> >> So, I was installing Oracle using your guide this time also.
> >> Everything looks fine, I got exact nuber of blocks when unpacked cpio
> >> (those who wanna know what is that number read the blog of the
> >> men :)), but the linking part fails. :( I would use some other OS but,
> >> i'm sorry to say that, it has to be on this one. :(
>
> >> Maybe some other packages need to be installed, i dont know. I found
> >> many artices regarding this problem but none of them helps. :(
>
> >> Please, if someone has the solution to this help me, because i'm
> >> getting an frustrating ulcer. :)
>
> > What bits about my earlier post did you not understand?
>
> > You're using Update 1, 2 or 3, not 4.4 of the OS. Therefore, you will
> > have to add in the deprecated libraries the exact name of which I
> > mentioned before.
>
> > I thought it was pretty clear myself: no need to appeal for "someone
> > having the solution". You already have it.
>
> You will also get these relink errors if your ORACLE_BASE is exported
> incorrectly. What I normally do is to ignore all this errorrs, and then
> afterwards do a "relink all" from the ORACLE_HOME/bin directly. I did
> many installs ifnoring them and then relinking manually afterwards
> without an error
>
> Lodewicus

I find that bafflingly and infuriating silly advice.

The guy is installing Red Hat 4. That's a completely standard OS, fully supported by Oracle, with guaranteed success for the installation. Nothing WILL go wrong *if* everything is done right. There is therefore no need EVER to "relink all" to make an installation of that database onto that OS work.

If you stuff things up so badly that you get a string of linking errors, you don't just ignore them: you call that a completely stuffed installation, wipe it and start again once you've corrected the underlying problem! In this case, the problem is one missing package. It needs to be installed and then the Oracle installation can be reperformed  from scratch.

If I ever had a junior come to me saying, 'Well, I got lots of errors, but I then relinked all and it that completed successfully', I would tell them to consider the install a miserable failure and to repeat it, properly, until such time as they achieve one that, from start to finish, doesn't produce any errors. And having made a silly and relatively trivial networking error on a Windows server a couple of days ago, I can attest that I beat myself up to the same standard, too: that particular server had its entire OS re-installed as well as a total re-installation of Oracle before I would declare that a success.

How in God's name you could ever manage to "export your ORACLE_BASE incorrectly" I don't have the faintest idea! The necessary configuration line (export ORACLE_BASE=/somewhere/or/other) is not exactly complicated. If you get that "wrong" it can only mean you can't type... or that you're too much in a hurry to check what it is that you're typing! Neither are good recommendations for best DBA practice.

Besides, the original poster is running a script of mine which he's lifted from my website and which I've used about a bazillion times to install correctly without fuss. So no, it's definitely not a badly exported ORACLE_BASE!

But that's really not the point here. The point is, DBAs don't patch things up. They get them right first. They pay due heed to detail and the need for accuracy, so misconfigurations of environment variables doesn't happen. At least, the good ones do. The others rely on workarounds such as the one you've just announced! Received on Thu Nov 08 2007 - 07:30:16 CST