Oracle 8.0.5 on RedHat5.2(Linux 2.0.36)- Kernel Config. Questions

Looking for wisdom, insight, and a step-by-step procedure:

I have the CD-ROM from Oracle8 release 8.0.5 Standard Edition for Linux, and I'm running Kernel 2.0.36 in a Red Hat 5.2 environment.

I'm working through the Installation Guide (referred to as the "manual" in the following text). I'm in no hurry, and I would rather get it robustly installed the first time than get it running as soon as possible. So, I'm trying to follow the instructions. Here's what I've come up with so far; please post replies to this newsgroup:

1. The first instruction in the manual under Configure LINUX Kernel for Oracle says "Use the ipcs command to obtain a list of the system's current shared memory and semaphore segments, and their identification number and owner." Specifically, what does this mean that I am looking for?

# ipcs

• Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 0 nobody 600 52228 11 dest
• Semaphore Arrays -------- key semid owner perms nsems status
• Message Queues -------- key msqid owner perms used-bytes messages 0x00000000 0 root 700 0 0

I did not find the man page on ipcs particularly enlightening.

2. In the next section, entitled, "Set the kernel parameters corresponding to ...", I have gathered (though I wish the manual said so explicitly) that these need to be set in the source for the kernel and that the kernel would then need be recompiled.
(OK, end of whining, now onto the nitty gritty.) I have the
Shared Memory and Semaphore parameters in Table 2-2 and want to plug them into the source.

First change needed, in file /usr/src/linux/include/linux/sem.h:

change #define SEMMSL 32 to #define SEMMSL 128

(I'll give a semaphore id 128 identifiers so that I can run 128
oracle processes. The max is 512 according to sem.h, so I took the goemetric mean, since this is intended to be a test bed.) I see no other changes needed in this file, and few implications that I'm going to cause major problems with this change. On to the next.

Second changes needed, in file
/usr/src/linux/include/asm-i368/shmparam.h:

Now, here's the part upon which I am really stumped.

change #define SHMMAX 0x2000000 to #define SHMMAX 0xFFFFFFFF

(I'm pretty sure that decimal 4294967295 is hex FFFFFFFF, though
the latter is a lot easier to write correctly!) I looked up a few lines and read

    SHMMAX <= (PAGE_SIZE << _SHM_IDX_BITS

Currently, PAGE_SIZE is set in
/usr/src/linux/include/asm-i368/page.h
to 1UL<<12 (0x1000).

However, _SHM_IDX_BITS + _SHM_ID_BITS <= 24 from a few lines above. And, from a few more lines above, _SHM_IDX_BITS is set to 15 and _SHM_ID_BITS is set to 7. So, either I can tweak the two BITS values or the PAGE_SIZE, right? (THIS IS NOT A RHETORICAL QUESTION. I WOULD LIKE YOUR INPUT!). However, to get SHMMAX to 2^32 with a page size of 2^12, I would need _SHM_IDX_BITS set to 20, which would leave only 4 bits for _SHM_ID_BITS, which woud lin turn put SHMMNI at 16, which is too low for the value recommended in the oracle manual, 100 (I wonder if that is really 100 or if it is supposed to be 0x100...). ANYway, It looks like I cannot do the whole job with _SHM_*_BITS, or even most of it.

This seems to lead me to adjusting page size, from 2^12 to 2^15. To do this, I'll need to alter /usr/src/linux/mm/kmalloc.c in order not to break the PAGESIZE-dependent structs. Does this make sense?

Has anyone (even at Oracle...) done this level of analysis when installing Oracle8 on Linux?
I saw that a few people have edited files, but few have mentioned which files, and I have seen no details at all on the changes made. Does this resemble the reasoning that they took? Do I really have to change PAGE_SIZE to pull this off? Do the instructions need to be changed? I think that they could be a little more explicit, IMHO.

If you have read this far, thanks very much! I look forward to your feedback.

-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own Received on Tue Dec 29 1998 - 09:15:54 CST