Upgrade Geodatabase, unchecked "upgrade" button, it ran anyway???

TracySchloss · ‎08-30-2013

I have an instance of ArcGIS Server that is still at 9.3, so I needed my geodatabase to stay at 9.3 until we are ready to upgrade. In the mean time, the Oracle DBA needed to upgrade the Oracle to 11g. Since my SDE is very old, a lot of the layers were still in LONG_RAW. I was able to get all my layers copied, migrated, whatever to ST_GEOMETRY.

As a last check, I had noticed that in the Upgrade Geodatabase dialog, there was an option to just "Perform Pre-requisite check", without actually doing the upgrade. I figured that would verify that none of my layers still had LONG_RAW, without actually doing any changes, and also verify that I was in good shape once I was ready to actually upgrade to 10.

I got several messages in the results, some telling me that I had some locks on the layers (which I didn't expect to see, since I had all my map services stopped) and also a permission error (I wasn't using the SDE administrator). In the end the Upgrade Geodatabase had messages in the Results that it had Failed.

Fine, it failed, I was only doing a check anyway. BUT MY GEODATABASE WAS UPGRADED ANYWAY! Now my ArcGIS Server 9.3 can't connect and I"m hoping that a restore from backup fixes this.

Is this some sort of 'Known Bug'? Is there maybe just a file that has a flag set that thinks the data is at 10 when it's really not?

This was not the expected outcome, especially since the geoprocessing results clearly say that the upgrade failed!

AsrujitSengupta · ‎08-30-2013

I think a query of the VERSION table at the database end will provide the best answer.....did the version of the geodatabase change to 10.x?
(login into SQLPLUS--> Select * from sde.version;)

If this shows as 9.3.x, then the gdb was not upgraded o 10.x....but something else might have occurred..

However, just running the Pre-requisite check shouldn't upgrade the gdb..

VinceAngelo · ‎08-31-2013

The difference between 9.x and 10.x will be stark -- Most of the GDB_* tables will
have gone away.

But it's still not valid to run an Oracle 10g geodatabase in an Oracle 11g instance,
so your upgrade requirement still exists (9.3.xsp? 10g -> 9.3.1sp2 11g).

I've had problems with failed geodatabase upgrades marking an upgrade unnecessary,
but never a non-upgrade upgrading.

You should of course have full upgrades at all times, but before a major upgrade an
extra cold backup is always a wise resource.

- V

TracySchloss · ‎09-03-2013

So far it sounds like no one has ever heard of such a thing happening. From the matrix I've seen, 9.3 geodatabases are supported by 11g Oracle. I'm not in a position to upgrade my geodatabase to 10 at this time, not because of the geodatabases, but because of my ArcGIS Server version. We don't have the resources to build the servers to support 10.1.

I'm having the data restored from backups today. If none of this works, I'm going to punt Oracle and just go to file geodatabases. This whole exercise is proving to be way more trouble than it's worth.

VinceAngelo · ‎09-03-2013

9.3.1 geodatabases are supported on Oracle 11g, but only with 11g-compatible
binaries and configuration. You cannot use a 10g geodatabase in 11g. It is always
necessary to upgrade the geodatabase instance when you change the database,
even if the "upgrade" doesn't result in a different version number.

To be clear: Your issue is the Oracle 10g->11g upgrade, not an ArcGIS 10.0 upgrade!

In order to make your database function correctly, you must install the 11g ArcSDE 9.3.1
SDEHOME, patch it with SP2 (since it's three years old, now), apply all the relevant post-
sp2 patches, transfer the configuration files from the ArcSDE for 10g install, and replace
the service. Then you must run 'sdesetup -o upgrade' before you can start the service
(or Direct Connect). You should then apply all the 9.3.1sp2 and post-sp2 service packs
to all your 9.3.x clients and servers.

- V

MichaelVolz · ‎09-03-2013

Tracy:

Do you have multiple SDE environments to perform your testing in (e.g. development, test, production) or are you just working in a production environment?

If you are just working in a production SDE environment, the problems you are encountering highlight the need for at least 1 other environment to perform your testing in so you have an SOP that you are highly confident with before upgrading your production environment. If budget is a concern, you can show how not having an additional SDE environment eats up person-hours and could impact production workflows for essential operations if they are tied to the SDE database.