SDE instance copy

[RobertWright1]

Yesterday I was trying to isolate my parcel fabric SDE database, and actually copied the instance to another virtual server.  When noticing that it was my version and that it still showed that I could reconcile and post my updates, I had expected that I created a one or two way replication.  As this was a test environment I continued to edit in the isolated database.  After I saved my edits I went to the original database with my administrative account and there was no replica created.  Yet all my edits showed up, and no rec-post was performed.  So some how, even though I was on a different server, I was still editing directly to the original SDE database.

One thing that was quite noticeable is that the file performance increased at its new location.

So now I have many questions.

1) Having this as a connected instance to the original, what is happening behind the scenes? 

         Will this cause problems later on in the database?

         How is it still passing information across between vertical servers, when there isn't a replication?

2) How will this affect the version, and versioning environment.

         Should the copied database instance be removed before compress, when other versions are removed?

2) Is this a valid work flow, as the performance dramatically increased?

I am not in our IT department, and do not have control of the of the SQL Server manager to look at the system tables. I am however one of the DBO admins for the database, and control operations through ArcCatalog. It was quite a shock on Friday when all this was going on.  Had me thinking about it all weekend.  So any insights on this would be greatly appreciated.

[JayStrahan]

When you 'copied the instance' to another server, did you move the database itself or just the .sde file? If you moved the database, what method did you use? Backup/Restore or Detatch/Attach? Walk me through the full process. 

[RobertWright1]

Good Morning Jay,

Actually all I did was right click on the database and Copy. Then created a folder to place what I thought would be a file geodatabase. Then posted the file. Normally I would have created a file geodatabase and copied the data set in. I was in a demo at the time and wanted to get the fabric data moved out of SDE, but not have to go through the whole rebuild and register of Parcel Fabric. So I took a short cut. We are in an isolated Test virtual server, with full duplication from our working environment. It (test server) was created as a SQL backup, then Restore.

Regards

Allen

[JayStrahan · Accepted solution]

Hi Robert, 

When you copy/pasted the .sde file, no actual data was moved, since no data exists in the .sde object. Think of that file as simply a reference for the software to find the database. You'll notice in the original and the copy that the instance, database, and user credentials are the same. You are still editing in the original environment. In order to copy the actual data, you'll need to right-click the destination folder, create a new file geodatabase. Go into the .sde connection, right-click the parcel fabric, Copy, then Paste in the new file geodatabase. This will be a static, isolated copy. 

[RobertWright1]

Ok, that make a lot more sense.

The next question would be why did it speed up the editing process?

Is this a valid edit work flow, will it cause problems with the original database in the future?

Regards,

Allen

[JayStrahan]

That's a great question. It's possible that since you were accessing the database from a different ArcGIS Desktop client, you might encounter different performance than from your PC. You could have your IT team run tests between the test server and the machine on which the database is hosted, then run the same tests between your PC and the database server. If there's a difference in performance, it might not be related to ArcGIS. To troubleshoot cases like this, it's useful to establish a baseline of equivalent tests run in different environments. That way you can determine which variables are important.