7 Replies Latest reply: Mar 12, 2013 1:11 PM by Murali Pasumarti RSS

    Hyperion DRM Performance Tuning


      Is there any documentation on how to fine tune hyperion DRM?
      I feel our DRM application is running slow. For example: To delete
      5000 orphan members would take 45 minutes. And to import
      a hierarchy of 40K members would take about 1hour 20 minutes.
      We are running version

        • 1. Re: Hyperion DRM Performance Tuning
          My comments in this thread would also apply to 9.3.x versions: Re: DRM Web is very slow

          If it has been getting a lot slower lately, you might want to explore whether regular database tuning has been done, i.e. are log files getting cleaned up and is the transaction history table getting cleaned up regularly.

          Also, how frequently are the versions being finalized and copied? If you're keeping the same version active for more than a month or on the outside a quarter that can create problems that you won't be able to tune your way around.
          • 2. Re: Hyperion DRM Performance Tuning
            Hi Naren,

            We are using SQL Server for the database and rebuilt the index of the database everyday.
            I will check whether there is a process to regularly clear the transaction history table and clean up the logs.
            Apart from the above, is there really any specific database settings that we need to apply on
            DRM database or a specific tuning exercise on the DRM application itself?

            Every month, we copy current version to a "temp" version. Once the "temp" version
            is updated with the latest hierarchy, we delete the current version and copy the "temp"
            version to become the current version.

            • 3. Re: Hyperion DRM Performance Tuning
              My knowledge of SQL Server is somewhat dated, but from memory we used to have jobs that periodically archived the data, dropped and recreated the tables, loaded the data, and the rebuilt the indices and constraints. DBAs told me that this was necessary in SQL Server to prevent the performance from degrading over time. This may not be required any longer but might be worth exploring.

              If you're copying versions monthly and deleting old versions your transaction history should pretty much be self maintaining.
              • 4. Re: Hyperion DRM Performance Tuning
                Murali Pasumarti
                clearing the transaction history table would not help and also it's not a best practice to do,as TH table is the which will help us if some thing went wrong,
                Try check with the DBA or also you can think of migrating to 11.1.1.X and then to 11.1.2.X,

                • 5. Re: Hyperion DRM Performance Tuning
                  Once upon a time the transaction history for versions was kept even if the version was deleted, but for quite some time that hasn't been the case. When that table gets large it isn't unusual to see as many as five or six additional indices added to keep queries generated from the UI performing well for various combinations of selection criteria.
                  • 6. Re: Hyperion DRM Performance Tuning
                    Nicola C.
                    Sorry about the question but Why clear the transaction history table it's not a best practice?

                    Thanks in advance,
                    • 7. Re: Hyperion DRM Performance Tuning
                      Murali Pasumarti
                      For Example you have cleared the transaction history table ( Deleting a Version) and you wish to check certain properties for it's previous value on a Node,
                      you can use STATS category to see when was it changed but that doesn't capture what was changed ( properties).

                      It's completely depend on your Business requirement to call clearing transaction history as a Best practice or not.

                      Edited by: Murali Pasumarti on Mar 12, 2013 11:11 AM