Notifications
Clear all
Topic starter
I used to use the import/export method, but begrudgingly switched to copying to a server with the same data file structure.
i'm interested in comparing notes with others who do this, if you are interested let me know.
it has become increasing complex over time, but I think I a reasonable process.
Posted : October 28, 2015 3:27 pm
I would be interested in this too.
Posted : October 28, 2015 6:30 pm
We're in a vmware environment. I haven't done this myself in a long time, so I'm probably missing something, but this is what we have documented.
In general, we clone our db and jboss server, rename them, change a few settings in jboss (maybe reinstall it in server setup), and I think that's pretty much it for basic testing.
Do you mean a full implementation with working interfaces and everything?
Posted : October 29, 2015 3:52 am
We use a old production server as our test server. We can do test upgrades as well as test backups from production. I was told the database name must contain test or demo in the name for licensing.
Posted : October 30, 2015 8:24 am
We do it by using our full sql db backup and restoring it to a test sql server. Then we have a second jboss server. Go into server setup on that test server do a web install, license, set user defaults and set standard jobs.
Posted : November 1, 2015 11:00 am
For those of you that restore production into test: how do you prevent the "test" database from then connecting to your production ancillary applications (portal, document manager, escript messenger etc). There is worry on our end that, if we do this, the test DB will automatically connect to these production applications because it thinks it is production.
I ask as we've been trying to copy our Live data into Test (to help with troubleshooting and to time the immunization migration tool) but that is the concern our server team has with a restore.
Thanks
Mike
Posted : November 2, 2015 4:52 am
If I had to re-do this today I would put our test environment on a completely different subnet and block access to the production environment. If I do recall we had linklogic start picking up production hl7 and had to remember to shut it off.. plus a few other interfaces we had to go through.
I seem to remember that we had to update the @@servername when we brought up our clone also (we changed the name to include clone)
SELECT @@SERVERNAME
sp_dropserver 'old_host_name'
GO
sp_addserver 'new_host_name', local
GO I have this on our notes about analytics (in case you run that):
NOTE: If you ever make a clone of the DB server running this analytic's job and its going to remain on the same network as the live DB you need to disable the daily analytic's on the clone. This job is hard coded to run with the original configured DB. If you do not disable this job and both jobs continue to run you will get mixed results with your reporting. It may seem fine one day but the next you may get missing data. There is also a query you can run that shows information about this job select * from practicemonitor (run against PICONTROL db). If you run this query and see the job runs more often than the scheduled time then you may have this job running from more than one DB
Posted : November 2, 2015 5:00 am
Mike,
You should be fine here. DM and ESM both point back to the live database and DTS. The test DB can access DM documents but no new documents will show up in the test DB. For ESM it points back to the live SQL DB so if you send a new ESM out of the test DB it will go nowhere. Biscom Faxing does work though since the CPS client sends directly to the Biscom server. Depending on the portal it might or might not be able to send to the live portal but any new messages should go into the live DB not the test DB for the same reason as DM. Hope this helps?
p.s.
For all we regularly run Audit Reports in our test systems and then use DM to import them into a Sensitive Audit Log Patient in the live DB. I do this so there is no gap in auditing even though I trust everyone who has access to the test DB.
Also this restore to test serves two other great purposes. One it tests your backup files and proves they work. Second it works great for a read only system during a major upgrade. For example if we upgrade to a new version of CPS I'll point everyone back at the restore of the live CPS db. I make sure the staff all know what it's current of. Used to be 1 day old but now that we do log backups it's within an hour or so fresh of the start of the downtime. Then we run Audit Reports at the end of the downtime to catch any documentation that was done when it wasn't supposed to be. Works great for places like mine that see patients 24/7/365.
Posted : November 2, 2015 5:20 am
Excellent Point here. If you do a clone CHECK ALL of your SQL JOBS and make sure only the ones you want are running. Especially if you have a custom job doing any work.
Posted : November 2, 2015 5:22 am
Topic starter
I suppose I should have specified EMR/Oracle vs. CPS. We are on Oracle.
I have a test DTS, but no test QIE, Esm or Portal.
I leave the instance name the same.
I have some scripts for updating some host names I'll share shortly.
Also after copying the Oracle files, I shut down prod, bring up test, and disable all production LL and DTS workstations from the interface and run the host update scripts.
I used to like the import/export through oracle method better because I could re-arrange drives and re-organize the data into logical data files, but not sure that is necessary now with oracle, but couldn't keep up with everything else that needed to be done using that method, re-enabling jobs and triggers, etc.
I appreciate the feedback, MedicalLogic used to provide better documentation on how to do this through the support organization, and they used to use the import/export method. Lets keep this list going.
Posted : November 2, 2015 3:48 pm
Topic starter
here are the quick little scripts I used last time, where EMR952 is the prod server, EMR98 is the host name of the new test server (you might need to use FQDN, we don't.)
//this updates references for to the JBOSS Server, we only have 1 and it is on the same windows server as the database.
update inetservices
set url=replace(url,'EMR952','EMR98')
//this is for the attacment paths
update extreferences
set moniker=replace(moniker,'EMR952','EMR98')
I'll have to look at what the SP above does, but as stated we leave our "server name" the same, just update the host name.
Posted : November 2, 2015 3:59 pm
When we were on Oracle we always used the cold backup to do the restore on the test db. I don't remember all the steps though. It's amazing what you forget when you don't use it.
Posted : November 2, 2015 7:16 pm
I have a running test environment which I built from scratch (CPS/SQL). I restore a backup of the production DB for all service pack/new version testing just to get a good idea about how long it will take to do production upgrades and to make sure there isn't any db corruption to cause a failure during the production upgrade. With VMware I can utilize the same hardware a production and also utilize the snapshot feature to back off any updates which did not go well.
There are a few things which are not easily put in this test environment like DTS, billing plug-ins, portal, fax server, eprescribing but it is very useful in determining what will be broken after a SP or release upgrade. It would be a lot more work as I would need a copy of all of those servers being that the test network is subnetted from production.
I would be using this same process if I was still using Oracle. Back then there was no such thing as a test server with a copy of production data blessed by GE. I wouldn't ever give this test environment up. In my last budget iteration I went from using old hardware to having extra SAN space to utilize the same hardware. That helps a lot. I LOVE virtualization!
Mike Zavolas
Tallahassee Neurological Clinic
Posted : November 4, 2015 6:08 am
