1 2 Previous Next 17 Replies Latest reply: Oct 15, 2013 3:31 PM by user5403674 Go to original post RSS
      • 16. Re: Essbase BSO Cube Sizes (11.1.2.3 vs 11.1.1.4)
        RobertR3

        So you're saying that a restructure brings it back down to size? That sounds like fragmentation.

        I see the block size is the same, which would indicate the dense dimensions are set the same. Have you made any storage setting changes to the Sparse dims?

        I had a case where a BSO planning cube, with a 500,000 byte lev0 file, racked up to over 80 gigs. The problem I found was stored children were dynamically calc'ed, and then those dynamic calc members were children to a stored member. Each time the intersection is referenced during an agg it has to dynamically calc the children before it can store the result. This results in mucho fragmentation.

        By making all sparse dim members never share, it reduced my agg time and DB size was only 10 gig after the agg.

         

        Robert

        • 17. Re: Essbase BSO Cube Sizes (11.1.2.3 vs 11.1.1.4)
          user5403674

          Unfortunately, I do not believe that this is not a new problem.  I encountered a very similar problem with Version 11.1.2.2.

          When several users were making increment updates to their applications, i.e., clear a section of the data and then reload or
          merely load more data; and then perform a default calculation utilizing the "Intelligent Calculation" option; the applications would just keep growing in size.

           

          In fact, I had one user crash Essbase because their calculation literally consumed all available disk space on the server. Unfortunately, I was not
          monitoring disk space usage at that time.

           

          I have used Essbase 7.1.6 and older versions for over 13 years and never experienced this phenomenon; therefore I submitted an SR.

          I believe that some members of the Development Team may now realize they have a bug; unfortunately, it was not fixed with Version 11.1.2.3.

           

          The suggested fix provided in my SR was to add a dummy member to a dense dimension,save at Level Zero, and perform a calculation.

          Or, essentially doing what has already been suggested – perform an optimization the application frequently.  Fortunately, I have

          not had any serious problems after I instructed the users to perform frequent optimizations.  Not the ideal solution!

              

          If anyone knows of a more efficient way to cure the disk hogging characteristics of the newer versions, please share the secret.

           

          There must be other users having this same problem.  Please share your insights.

           

          1 2 Previous Next