5 Replies Latest reply on Dec 5, 2012 2:53 AM by user13040806

    temp files in app directory

      In a few different 11.1.2 environments, I've seen files named temp123456789.txt within a specific application's directory on the Essbase server.

      For example:

      Directory of D:\Oracle\Middleware\user_projects\epmsystem1_ESSBASE\EssbaseServer\essbaseserver1\app\MyApp

      07/26/2012 12:58 PM <DIR> .
      07/26/2012 12:58 PM <DIR> ..
      11/15/2012 11:22 AM <DIR> MyApp
      11/19/2012 08:41 AM 195 MyApp.apb
      11/19/2012 08:41 AM 195 MyApp.app
      01/19/2012 02:56 PM 1,405 essbaseapp.instance
      07/25/2012 10:28 AM 761,209,498 temp212097848732614.txt
      06/21/2012 10:19 AM 2,147,451,124 temp438423982445533.txt
      06/21/2012 10:25 AM 280,993,025 temp438423982445533_1.txt
      07/26/2012 12:58 PM 2,147,451,116 temp468750742449448.txt
      07/26/2012 01:04 PM 340,247,592 temp468750742449448_1.txt
      8 File(s) 5,677,354,150 bytes
      3 Dir(s) 184,011,628,544 bytes free


      This has caused a problem in a few of the environments I've been on as these large files get copied when the app gets copied, causing the box to run out of disk quicker.

      Can someone tell me what these files are? When are they generated and why?

        • 1. Re: temp files in app directory
          I've seen this or read about this and I think these are artifacts from EAS processes that never complete. Were you doing something like an export (that 2 gig file seems awfully like the 2 gig export file limit) that didn't complete all the way for some reason? Can you go back to the app log or Essbase log on those dates and see what was happening at that time?

          I know that when you put a BSO database into archive mode Essbase will right a file to the database directory indicating the locks (I think I am remembering this correctly) but you're looking in the application folder, so I don't think that holds true.


          Cameron Lackpour
          1 person found this helpful
          • 2. Re: temp files in app directory
            It might be worth skimming through the log for that app and seeing what essbase activity was going on at that time
            1 person found this helpful
            • 3. Re: temp files in app directory
              I'm having the necessary technical people try to restore the logs from July now. I'll post when I have something. Thanks for the input!
              • 4. Re: temp files in app directory
                Just wanted to post and say that I found the culprit - LCM. For some odd reason, when we kick off LCM backups at night, the data exports as these temp files then never gets erased.

                Here's the LCM definition I was using (in case anyone was curious):

                <?xml version="1.0" encoding="UTF-8"?>
                <Package name="web-migration" description="Migrating Product to File System">
                <Credentials user="batchuser" password="my password"/><LOCALE>en_US</LOCALE>
                <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection"/>
                <ConnectionInfo name="FileSystem-Connection1" type="FileSystem" description="File system connection" HSSConnection="MyHSS-Connection1" filePath="D:/BACKUP/LCM/ESSAPP_AppName_deployment_metadata_MigrationDefinition"/>
                <ConnectionInfo name="AppConnection2" type="Application" product="ESBAPP" project="EssbaseCluster-1" application="AppName" HSSConnection="MyHSS-Connection1" description="Source Application"/>
                <Task seqID="-1">
                <Source connection="AppConnection2">
                <Artifact recursive="true" parentPath="/Configuration" pattern="*"/>
                <Artifact recursive="true" parentPath="/Substitution Variables" pattern="*"/>
                <Artifact recursive="true" parentPath="/Databases" pattern="*"/>
                <Target connection="FileSystem-Connection1">
                • 5. Re: temp files in app directory
                  I spend the same. The solution to the problem was to review the logs of the application and change the password of the user that these files were being generated. I never knew the reason of the problem.