how do I know which which oracle instance created this share memory?

[Hanry Zhou]

when I run ipcs -ma, it shows me the list of share memory segments, and also the owner of each one of them. for these owned by oracle, how do I know which instance has created the segment?

Although there are columns called "CPID", and "LPID", I could not find the process id under these two columns by using ps -ef. what is CPID, and LPID?

[James R. Ferguson]

Hi Hanry:

CPID = The process ID of the Creator of the shared segment.

LPID = The process ID of the Last process attaching or detaching from the shared segment.

Regards!

...JRF...

[Hanry Zhou]

Yeah. But, still I can not find whico oracle instance or process when I do ps -ef on either CPID or LPID. I have multiple instances, and corresponding multiple shared segments. How do I know which instance is to which shared segment from the output of ipcs -ma?

[Ninad_1]

One way would be to connect to Oracle as system or sysdab and issue show sga
and then compare the SGA size with ipcs -mb to see which segment size matches the SGA and then you can corelate the Oracle database instance and the segment ID,

Regards,
Ninad

[Hanry Zhou]

Yeah. I know. But, is not it a way to figure out myself by using UNIX commands, or tools without using any Oracle dba commands?

[Hanry Zhou]

Yeah. I know. But, is not it a way to figure out myself by using UNIX commands, or tools without using any Oracle dba commands, and why I could not find any either CPID, or LPID by using ps -ef ? are these processes gone already when I run ps -ef?

[TwoProc]

Well, I usually handle this by starting each instance with a different user (not Oracle).

But, short of that, the easiest way is to review the ipcs display and look at the time the memory chunks were allocated. These will match up nicely with the start times in the alert log of each database, and figuring out which database has which memory area becomes quite simple at that point.... UNLESS you happened to start two databases in the same minute.

[Hanry Zhou]

Yeah. But, what is the reason I could not find any existing porcess ID by ps -ef on either CPID, or LPID?

[TwoProc]

Because those processes are now gone. And their memory segments weren't cleaned up. This would be because the program didn't clean up on the way out. This is due to a) bad programming b) program crash (see a)), or c) the program was forced down with a "kill -9" and couldn't clean up. So, the mem segments are still out there for thew now non-existant program that allocated the space.

[Hanry Zhou]

John,

I have a few questions and would like to confirm with you.

1. I thought these Oracle segments listed here by usimg ipcs -ma are corresponding to each one of SGA. But, from your previous response, you seemed like these segments should have been removed because of processes who created/used the segment is gone. I am not sure that is the correct statement, because I can not find any one of CPID/LPID for any segements.

2. If they are no longer needed, can I remove those segments? because we have been udner memory pressue

[Ninad_1]

Hanry,

I dont have answer to your question why you cannot see the PIDs, but I can definitely tell you that 99% chances are that the segments owned by oracle would be corresponding to the databases running.
John is right but for oracle databases its been my observation as well that the PIDs are not traceable, but the segments are still in use by the database which is running perfectly fine.

Regards,
Ninad

[A. Clay Stephenson]

Old, unused/unattached shmem segments are typically the result of kill -9's. In that case, the application couldn't do cleanups even if it wanted to.

Whether or not it is safe to remove a given shmem structure via ipcrm depends upon the design of the application. Even in the case where NATTCH =0 and the CPID and LPID do not correspond to existing processes, it may still not be safe to remove the shmem identifier. It's common to have some sort of initialization program setup shared memory and then exit (NATTCH = 0, LPID & CPID would then reference a non-existant process) so that later applications can start much faster but they expect the shared memory to be there.

In the case of Oracle, if NATTCH = 0 and CPID and LPID no longer exist then it is safe to remove the identifier.

[Hanry Zhou]

If these segments are really Oracle instance SGA's, they should stay there, and should always have an exising and assoicating process, unitl the instance is ended. right?

[Patrick Wallek]

I just ran a test on one of our Oracle machines. On this machine there are 5 shared memory segments owned by Oracle. On 2 of them, I was able to find the LPID via a 'ps -ef'. I was not able to find the CPID on any of them.

However, all 5 have a NATTACH value that is greater than 0, so they are all still in use.

The key in your case, as I think someone said, is to look at the NATTACH column. Do NOT delete the segments if NATTACH is greater than 0, otherwise you may crash your DB.

[TwoProc]

H,

I see the problem that you're having. I just looked at a number of our Oracle instances, and, just like you're describing, the are no matching processes like the CPID on any of our running instances either.

STOP!
Please ignore my previous posting then!!!
STOP!

This is probably because the process that starts oracle (sqlplus/svrmgrl,possibly) goes away after oracle is started. The theory would be correct, I just don't know if it is really sqlplus or svrmgrl that had the proc id. I'd have to test it to be sure.

You'll have to go back and review the time stamps for "ctime" from "ipcs -am" display and review what you see in the alert log for start times from the candidate databases. If you've got a match, then that's your database.

Do you have any databases down right now? Or any that went down that makes you suspect some of the memory was left behind?

I can almost promise you, if the databases were brought down normally, then all of those memory segments belong to a running database.

Once again, verify the ctimes with the start times of the databases in the alert logs.

[A. Clay Stephenson]

Essentially, if you see NATTACH = 0 and the owner and creator are oracle (or whatever user is associated with a particular Oracle instance) and LPID and CPID no longer exist then is PROBABLY safe to remove the shmem structure. Certainly a legitimate Oracle SGA conforms to this principle; however, consider the case of a setup application like I mentioned above that happens to be executed by user oracle. It would have identical characteristics and would satisfy the above removal criteria BUT a subsequent client startup attempt would fail because the shared memory identifier could not be found. In order to know when it is safe to remove IPC structures, one must know the apllications.

[Ninad_1]

Ok your best bet will be as follows

If you oracle database sid is say oradb1
then
ps -eaf | grep oradb1 | grep -v grep | wc -l
this will give you oracle processes connected to the segment.
Verify this figure with the ipcs -ma - NATTCH - to guess which segment corresponds to this SID. Also in database check sga size as I told you earlier and cross verify the size with the NATTCH line - segment size.

Regards,
Ninad

[Hanry Zhou]

My primary question now is, whether or not these listed Oracle segments really are corresponding each one of Oracle SGA's?

I have 9 listed Oracle segments by ipcs, and meanwhile I have 9 instances running on this server.

[TwoProc]

OK, just did a test on a test database.

Before I started it I noted the process id of the "sqlplus" session I was in (21855).

After it was started, I exited sqlplus and examined the CPID and it was 21856 (one number higher). Since this is a pretty idle test server, it was probably the process spawned by sqlplus (probably "oracle") which started things and went away... Since I've got a fairly large SGA, which takes some time to startup on this old slow test server, it gives me time to try and capture all the process id's in the system during startup into a file.

I'll try that next...

[TwoProc]

CPID might be the shadow process...
testing...

[TwoProc]

OK, I've got it figured out what the CPID is and how it relates to the starting of the oracle processes.

My current CPID is 22975.

This WAS the process id of my Oracle shadow process (my oracleDBDEV DESCRIPTION=( "LOCAL=YES")) associated with my current sqlplus session (still running) before and during the Oracle startup.

Once oracle was up however, that shadow process is gone, and the shadow process holding up my still running sqlplus session is now 23209! [ I know this because I started the database in restrict mode ].

This means you won't find a matching cpid for ipcs -am after the database has been started because even if you stay in sqlplus, the shadow process that starts the database is terminated and a new process is now associated with the still running slqplus system connection that started the database.

Anyway, this explains why you can't see your CPID, which is normal. In other words, just because there is no matching CPID, you can't assume that you need to remove those memory segments.

[Hanry Zhou]

Thanks all for your responses.

The only question I'd like to know now is, whether or not these listed Oracle segments really are corresponding each one of Oracle SGA's that is defined in Oracle?, and thefore it's size is same as SGA size?

[TwoProc]

I just looked at the SGA I just created and the shared memory segments created for me, and I see no direct relationship between the sizes of the shared segments and the sizes of declared sga pieces I constructed - except in their total, but not for each piece of the memory segment.

From my review it looks like the various segments have combined purposes, and you can't say that one segment is the shared pool, another is the large pool, another is the java pool, or another is the buffer_cache.

[Bill Hassell]

As you haqve seen in the above tests, shared memory can be tossed around with all sorts of processes attaching, or very short-lived processes actually creating the segments. Oracle (depending on the version and size of SGA) may create a single segment or several segments for a given instance. But alas, the instance information (which is really an internal Oracle ID) won't be found in the segment details.

The only two solutions have been mentioned:

-- start each instance as a separate user (ie, oracle1 oracle2 oracle3...

-- modify the start/stop script(s) for your Oracle instances to provide a delay between each instance, perhaps a sleep 20 or so. The reason for the delay is to ensure that each instance has time to create their SGA tasks for a reliable start time. And in the start/stop script, write out the start time for each instance to a file, then use the ATIME value from ipcs -ma to find a match.

[TwoProc]

Hanry, you've been getting some good help for quite a while, and you're no longer new here.
We're all glad you're part of the forums, and it would be really cool if you read the following:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=140137

And also this interesting thread:

https://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1033211