5 Replies Latest reply on Feb 21, 2011 11:12 PM by NN

    FDM Work and Work Table Index Tablespace


      According to FDM_Admin guide, Working with Tablespaces for Work Tables and Work-Table Indexes section. It is advised to create a separate tablespace with NoLogging.

      When I ask our DBA about this, he mentioned that this would cause an issue with hot backup. Here is his comments:
      "The problem is that we cannot guarantee the recovery of this database unless we recover from a cold backup. This means if there is anything on that database that is important, we are going to have problems with protecting the data." He said, applying no logging will affect the ability to recover the database in the event of failure, even though the Work tables is a temporary tables only. His opinion is that when the backup happen at the same time as when the table is created, will result invalid backup. The only way to backup the database is to issue a cold backup, which means we need to stop the application to do the backup.

      Is this true?

        • 1. Re: FDM Work and Work Table Index Tablespace

          Unfortunatley this is not a question for the Hyperion Product line. The FDM Admin (DBA Guide) has clearly outlined what is needed and required.
          If this is conflicting with what your DBA is stating .... then you might want to ask fellow 'DBAs' ... not Hyperion Admins.
          I would suggest you post your query about your backup strategy with tablespaces to the appropriate group.

          Thank you,
          • 2. Re: FDM Work and Work Table Index Tablespace
            Also another note, having logging enabled on the work table tablespace will hinder import performance at a large rate. All of the historical data and historical mapping is stored in the tdataseg and tdatamapseg tables, this is the most important part of the database backup process to make sure that these are backed up properly.
            1 person found this helpful
            • 3. Re: FDM Work and Work Table Index Tablespace
              John A Booth
              Realize performance can be at odds with backup practices at times and this is such a case here. The logging being on stores the transaction logs which causes a lot of extra I/O. Turning it off will make it faster however if it's fast enough with the logging on then there really isn't a problem.

              The DBA's point is if there were a failure you would have to go to the last cold backup -- cold backups require the database to be totally shutdown an offline which may have impacts on your system uptime. Oracle does recommend a separate instance for FDM however it's not always implemented with a separate instance. Assuming your FDM is on a separate instance they should be able to implement more frequent cold-backups -- which means a daily outage of FDM for whatever time they can schedule in their backup window.


              John A. Booth
              1 person found this helpful
              • 4. Re: FDM Work and Work Table Index Tablespace

                Unfortunately there are a few 'points-of-interest' here.

                1. For FDM there is never a need for a "cold-backup". FDM does not maintain a persistent connection to the DB.... nor does it do work in a permanent resting spot. That is the whole point of FDM using a temporary work space. The data can be dropped/deleted/crashed/exploded without harm to normal data.
                2. If the instance requires to be shut down... why isn't the database running in ArchiveLogMode to prevent such factors?
                3. Performance of an import is crucial... if not they would not have documented such.

                Again .... to address the larger concerns that the DB group has brought forward requires a lot more information than what can be addressed in this forum thread... and would encourage the appropriate people to converse.

                Thank you,
                1 person found this helpful
                • 5. Re: FDM Work and Work Table Index Tablespace

                  Thanks for the replies. It is all helpful.
                  Just a few point to clarify. Our FDM is on a separate database, which only have one schema for the FDM.
                  When you said FDM does not maintain a persistent connection to the DB, is this mean that a hot backup
                  should be sufficient? I'm asking this to the forum to understand how the backup it being implemented on other