Mary,

If you are on Oracle, you can write a script that exports the database 
structures first, then followed by the data, ignoring data in the application 
forms (such as incident, change etc) and take across all other data such as the 
meta data (which is important), foundation and configuration data, and any 
other custom application you may have that might have configuration data.

You could write a script to auto generate par files, that will selectively 
export data and selectively import data. This will save you a lot of time, in 
case you have a lot of application data in your system. On one occasion doing 
something like this cut the full time to export and import a production 
database to a test database from something like 10 to 12 hours to under 2 
hours..

This script can be written in DOS that could use the SQLPlus client to exp and 
imp the structures and then the data, based on the parameters in your par 
files.. You can also auto generate these par files in your script..

Joe
  -----Original Message-----
  From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org]on Behalf Of LJ LongWing
  Sent: Monday, June 07, 2010 5:06 PM
  To: arslist@ARSLIST.ORG
  Subject: Re: An efficient way to sync up data


  ** 
  We made it easy on our selves….all of our mailboxes/test users/etc are in 
production but disabled.  When we refresh Dev/Test here are escalations that go 
through and enable ‘that server’s records and disables everything else…we also 
setup a filter on the email engine that basically says

   

  THIS IS COMING FROM A TEST SYSTEM

   

  At the beginning of ALL emails that go out from our non production 
boxes….helps cut down on the ‘taking action on a production ticket’ scenario 
when it comes from the test system.

   

  From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Ramey, Anne
  Sent: Monday, June 07, 2010 2:54 PM
  To: arslist@ARSLIST.ORG
  Subject: Re: An efficient way to sync up data

   

  We've done this and developed a little document with all of the references in 
ARS and ITSM to the production server and how/when they need to be changed 
during/after the sync of the DB.  It's worked well for us once we worked out 
the details.

   

  Anne Ramey

  ***********************************

  E-mail correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties only by an 
authorized State Official.

   

  From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Kelly Deaver
  Sent: Monday, June 07, 2010 4:25 PM
  To: arslist@ARSLIST.ORG
  Subject: Re: An efficient way to sync up data

   

  ** 

  You can have a problem with copying the database if you have the ITSM apps, 
use the email server and any number of other places where configuration data is 
stored in the database. References to your production server will now live on 
your test server. I have personally seen this situation and had the test server 
looking over in the production server to send email notification.. we were 
wondering why they were all going out twice!

  Kelly Deaver
  L-3 Stratis / FAA Contractor

  kdea...@kellydeaver.com (ARSlist mail)
  kelly.ctr.dea...@faa.gov (Business mail)

   

   

    -------- Original Message --------
    Subject: Re: An efficient way to sync up data
    From: pritch <pri...@ptd.net>
    Date: Mon, June 07, 2010 2:48 pm
    To: arslist@ARSLIST.ORG

    Hi Mary,

    When I've done this in the past, we've copied the database from production
    back to test, removed any 'sensitive' data and then migrated any coding
    updates that needed to be changed. A couple of items to watch for:

    - You need to make sure your ARAdmin ID to the DB is the same (or have it
    reset)
    - All your workflow needs to be server independent (you can export to a def
    file and evaluate)
    - All test user accts will need to be reset (I've usually exported those
    and imported after the database is restored.
    - probably need to check external interfaces and application settings to
    make sure they are pointed properly.

    With all the ancillary forms that are used in remedy, I've found this to be
    the easiest way to get all the data moved intact.

    pritch

    On Mon, 7 Jun 2010 12:05:40 -0700, Mary Estrada <mestr...@blizzard.com>
    wrote:
    > Hi,
    > 
    > We are looking for suggestions to sync up all data, i.e. foundation,
    > configuration & transaction data from our production server onto our test
    > server where we need all the prod-like data and keeping all record IDs in
    > their forms. Your feedback is gratefully appreciated.
    > 
    > Thanks,
    > 
    > ~Mary

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

Reply via email to