3 Replies Latest reply on Mar 22, 2019 5:36 PM by Marie Johnson

    Setting up replication to Read Only ARS database for Smart Reporting.

    Randy Evans-Strum

      sorry if this isn't the right place for this questions.   But is anyone using Smart Reproting with a Read only replciated ARS database in Oracle?  if so how are you replicating it?  How often are you sychronizing it? 





        • 1. Re: Setting up replication to Read Only ARS database for Smart Reporting.
          Stefan Hall

          I don't think there can be a right wrong answer, it depends on your requirements.

          If your customers want real-time information, it wouldn't be bad right away. If a daily overview is enough for them, then once a day at night.

          We use an Oracle Database with RAC/Dataguard and have real-time data, but update most reports only once a day.

          • 2. Re: Setting up replication to Read Only ARS database for Smart Reporting.
            Randy Evans-Strum

            Real time synchroized is probably more then what we need.  Plus we don't have RAC/Dataguard so there would be a cost associated with it.  The DBA's I'm working with a interested in something called Oracle Streams.

            • 3. Re: Setting up replication to Read Only ARS database for Smart Reporting.
              Marie Johnson



              Stefan Hall, is correct that the correct answer depends on you as there are many options.   


              One thing that I do want to point out is that Smart Reporting requires ITSM licenses and Remedy API in order to legally and functionally use it.  Now you maybe saying yes I have that, but let me point out that you have licenses for your productive Remedy ticketing server, not for a productive Remedy Reporting server (different production environment). Depending on who will use it, you will want the same roles and permissions on the Reporting server so that privacy remains intact.   While you’re saying read only, the truth is some reports will need new views and joins.  Not all users will be making these types of reports but some will and as the power of YellowFin is seen usage will grow.  Please just think about that when you’re looking at a solution.


              Sorry for the digression...

              It it sounds like you’re looking for a poor man’s replication option!  Don’t read that as negative, it just means you want to use what you have in house and not buy anything, even if there is a tool that does exactly what you want.


              so there are remedy options, database options, and OS level options, which sounds better?


              the OS option you’ll copy the files to another location and use them in oracle, the DBA will need to run a script to change the DBID and Then set the database to read only.  This is typically quick but any views and joins that were created by the report team would be gone each day, plus any report IDs would have to be reestablished.  the plus is almost anyone know how to copy a file and this method can become zero touch pretty quickly.  You still need remedy because the api Uses it to create the reports and you need to still keep your permissions in tact so people do not see data they shouldn’t especially true if you have HR data or something that needs privacy.


              the database options are you can establish replicas, create stored procedures and triggers.  Oracle has the DUPLICATE function. With this function you can set the source and target and even specify a date, something like:


                FROM ACTIVE DATABASE

                PASSWORD FILE





              DUPLICATE DATABASE prod TO dupdb

                TO RESTORE POINT TESTDB103107

                DBID 8675309 # DBID of source database



              The dba should be able to perform this for you pretty easy.  The negative is as your dB gets bigger it takes longer.  With MSSQL you can take the transactional Logs and load them each night onto the archive dB, I’d assume oracle has a feature like this as well, I’ve Just never used it as I replicate like Stefan!  

              Also, once the dB is copied you can keep it up with triggers on the dB side.  This negatives are developing all this on the db-side Makes it a bit of a mystery and hidden thing that can get lost with upgrades, new personnel, server changes, hostname or is changes and so on.  Same thing as OS solution you need a remedy server pointing to the dB and the remedy api.  The plus is that dB data migration is very fast plus it’s off your plate.  If the dba don’t like doing it then they can invest in real tools that do the job.


              the remedy solutions would still require a dB copy or replicate at some level, and then to keep up the data, you can use code, AI, orchestrator, migratory,DSO, or even flat file exports and imports.  Lots of options some worst than others and some would give me nightmares implementing but they are still options. the negative with anything remedy is it uses the API and it’s SLOW.  It can be tedious to setup but it will typically upgrade and migrate easily.


              the last option which is how many do it, is to point Smart Reporting at the production dB And let people use their standard ids and permissions.


              oh I guess there is a final option and that is to use a different reporting solution that wouldn’t require remedy Api. But the negatives to this are that the security of the data will not be upheld and you’ll also have to write everything yourself.


              so to pursue the correct direction, really depends on your organization, the skills and time available by your people in the company, how much data there is to migrate/replicate, how often it is needed, how many reports will be done, and what tools you have available.

              1 of 1 people found this helpful