Storage server almost full (+90%). I need to remove dmp file

[fastja_k]

hi,

In case, storage server which installed IBM Cognos almost full. we use RHEL. after i search where the big file is located, it's in /ibm/c10_64/bin64/, and bang! it's core.ProcessID.dmp file

is it okay if i delete it? it's more than one file, based by date format

-rw------- 1 root root 1.6G Dec 10  2015 core.20151210.194439.22080.0008.dmp
-rw------- 1 root root 1.6G Dec 10  2015 core.20151210.194439.22080.0005.dmp
-rw------- 1 root root 1.6G Nov 18  2015 core.20151118.193025.5718.0003.dmp
-rw------- 1 root root 1.6G Nov 18  2015 core.20151118.193025.5718.0006.dmp
-rw------- 1 root root 1.7G Dec 21  2015 core.20151221.194704.31721.0001.dmp
-rw------- 1 root root 1.7G Dec 21  2015 core.20151221.194704.31721.0009.dmp

if not, why? if i can do it. is there will be any problem with Cognos?

Thanks for your attention.
:)

[MFGF]

hi,

In case, storage server which installed IBM Cognos almost full. we use RHEL. after i search where the big file is located, it's in /ibm/c10_64/bin64/, and bang! it's core.ProcessID.dmp file

is it okay if i delete it? it's more than one file, based by date format

-rw------- 1 root root 1.6G Dec 10  2015 core.20151210.194439.22080.0008.dmp
-rw------- 1 root root 1.6G Dec 10  2015 core.20151210.194439.22080.0005.dmp
-rw------- 1 root root 1.6G Nov 18  2015 core.20151118.193025.5718.0003.dmp
-rw------- 1 root root 1.6G Nov 18  2015 core.20151118.193025.5718.0006.dmp
-rw------- 1 root root 1.7G Dec 21  2015 core.20151221.194704.31721.0001.dmp
-rw------- 1 root root 1.7G Dec 21  2015 core.20151221.194704.31721.0009.dmp

if not, why? if i can do it. is there will be any problem with Cognos?

Thanks for your attention.
:)

Hi,

These are core dump files from where your cognos processing crashed. It looks like the dates are from November and December last year, so they are pretty old. It's fine to delete them.

MF.

[fastja_k]

Hi,

These are core dump files from where your cognos processing crashed. It looks like the dates are from November and December last year, so they are pretty old. It's fine to delete them.

MF.

Hi  :)

Yeah, they are last year dmp files. actually, i'm just zip them now, so the storage can be saved 3-5%.  I don't delete them till i know if it's okay to do it. so, thank you for your advice

FK

[smiley]

Feel free to throw them away.
They are only usefull for analysis by IBM support on specific cases.

You can have bibus dumps (bad 32 bits report), java dumps (bad 64 bits report, or java engine dump) and core dumps (BI system problem)
Delete for now. (If you don´t, it could potentially stop BI workability, due to bin folder location)
Even better, run a script to delete them monthly.

If they continue to be created, you better also investigate the cause.

[fastja_k]

Feel free to throw them away.
They are only usefull for analysis by IBM support on specific cases.

You can have bibus dumps (bad 32 bits report), java dumps (bad 64 bits report, or java engine dump) and core dumps (BI system problem)
Delete for now. (If you don´t, it could potentially stop BI workability, due to bin folder location)
Even better, run a script to delete them monthly.

If they continue to be created, you better also investigate the cause.

thanks for your advice,

What i thought about this, dmp file help the IBM support to investigate. I just keep them in 1 month, as your recommendation to delete it. Anyway, in the past 2-3 months our Cognos BI have been restarted in several times cause some error, maybe one of the cause is it by this dmp file which pile up?

[smiley]

A dmp file is created as a result of the problem, not the cause.
All running logic in memory is written to such a dmp file.

If you leave them there however, they pile up, and then when the disk system or mount point where BI runs get´s full, then yes it can be the cause of new problems.