I was hoping some people can help me in trying to figure out how
this happens.
We're running Essbase 4.1.2 Patch 3 and have seen a situation where
the Essbase security file (essbase.sec) gets corrupted.
When this happens we delete the security file and restart essbase.
We enter the same user id and password. However all applications in the
essbase server are gone. What we've done is do the simple create new
application, enter the old application name and voila, it comes back.
My question is what causes the security file to get corrupted in the
first place? I know it's linked to the essbase and corresponding server
processes, but what would cause it to get corrupted?
If anyone can shed some light it will be greatly appreciated.
Many thanks!
Sincerely,
Altan Khendup
PeopleSoft, Inc.
When your Essbase agent starts, a file is created, essbase.bak, that is a
backup of your essbase.sec file. When the essbase.sec file becomes
corrupt, you should copy your essbase.bak file over your essbase.sec file.
Your essbase.bak may be fine and you could therefore prevent having to
recreate all security information on your server. A good practice is to
bring down the agent any time substantial security has been added, since
the backup will be created when the agent restarts.
Unfortunately I have nothing to add on why the file becomes corrupt or how
to prevent corruption.
Good luck to you,
Sarah Dick
In your Essbase\Bin directory on the server is the security file called
Essbase.sec, also there is a backup file called Essbase.bak. Rename
Essbase.bak to Essbase.sec and you should recover the security settings
(except for the last change you made to it).
This is the theory, I have not tested it so check with Arbor before trying
it. At least it is less drastic than deleting the Essbase.sec file and
starting from scratch.
Alain Jaques.
ATLAN KHENDUP wrote in message <355C9D20...@Peoplesoft.com>...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KalDar
Kal...@mailexcite.com
Real name and address concealed to protect mail server and inbox.
Responses to the above address will be read, spam will be blocked.
Which reminds me. Time to go chase your tail little spambot....
http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi
I'd like to thank everyone who responded. The essbase.bak solution works
for most of our crashes. We definitely bring the server down after
significant security changes.
However, in at least two of our corruptions, the essbase server process
died. Looking in the logs it seemed to be linked to some form of NFS problem
for our disks. After such a corruption we tried using the .bak files to no
avail. Essbase still did not recognize the lost apps. Luckily we had a
backup as well.
It seems that in most of the cases where the actual server process
crashes various files are left in a questionable state. Even the back-up
files. In certain cases even the backup of the .db and .app files don't help
for certain application and database recoveries. We're looking into the
problem surrounding using NFS disk volumes for our large storage
requirements for our apps.
But the .bak saves us much more time and effort.
Again thanks everyone!
Sincerely,
PeopleSoft, Inc.