I noticed on the geodatabase (dataset) upgrade documentation for 10.7.X that something says (checklist item): Have all custom functionality added to the geodatabase system tables outside ArcGIS, such as triggers or additional indexes been removed?

[JohnPavek]

I would like to know is there a way around this step?  We are going from 10.2.2 to 10.7.1.  It is going to add a lot more hassle trying to minimize the downtime for the Production.  We have to take things out, do the upgrade and put them back in hopefully as it was before without issues.  If we could just do the upgrade without this step we can save time and not risk issues when things are put back.  THANK YOU ALL!

[JohnPavek]

I see some views of this but no answer yet.  So just to make sure people know the question...I noticed on the geodatabase (dataset) upgrade documentation for 10.7.X that something says (checklist item): "Have all custom functionality added to the geodatabase system tables outside ArcGIS, such as triggers or additional indexes been removed?"  I would like to know is there a way around this step for us? 

[George_Thompson]

I am not sure that there is a way around this in a safe and supported manner. I would highly recommend following the upgrading steps to make sure that it is successful.

I would recommend taking a backup and restoring to another instance and test the upgrade process to determine potential downtime.

[JohnPavek]

I appreciate George's answer very much!  But it really is a pain dealing with that esp in such a highly customized environment like I'm now in.  

So the next question in the progression is...what specifically has to be removed and is there any documentation that details this action?  If we have to remove things like user tables, non-sde that is going to be a pain but if it is just anything in the SDE tables still a pain but not as bad.  Can somebody give me info on this please...pretty please? :-).  If this is majorly involved we may just do a migration method instead of upgrade.

Thanks again George!

[MarcoBoeringa]

You do not specify, except a brief mentioning of "user tables, non-sde", what it actually is that constitutes your "highly customized environment"...

You could have a "highly customized environment" which still behaves entirely, and acts within, the geodatabase concept, but only a review of the applications / extensions involved and contacting the parties who developed it, should tell you this.

I don't think having some "user tables, non-sde" is necessarily a problem if that is the only true "customization" you have done. If I quote your quote of the docs, it says:

Have all custom functionality added to the geodatabase system tables outside ArcGIS, such as triggers or additional indexes been removed?

which specifically references the actual geodatabase system tables, not user tables or non-sde stuff inside the same database. So, the first question for you to answer to yourself is, do you have custom "triggers or additional indexes" set on the geodatabase "system" tables to implement some of that "highly customized environment"?

If not, you are likely safe upgrading the geodatabase.

That said, I would certainly take George Thompson‌ 's advice and ensure you have a full - and restore tested(!) - backup of your geodatabase before doing any upgrading of the geodatabase environment. You will be even worse off if anything fails and you don't have a working backup to quickly restore your environment.

[JohnPavek]

Hi Marco

Thanks for the reply.  Believe me I agree with George major...unfortunately they didn't do backups as much as they should of here in the past

I'm trying to get more info about the "highly customized environment".  But I know they have made many changes to give clients very specific functionality.   I wish I had specifics right now but this just became a major issue last week.  I have avoided large amounts of customization in my career just because of issues like this.  Back when I started in the 1980's we needed it because GIS was still coming out of its infancy.  Eventually I got rid of almost all of it.

Like most geodatabases we have an SDE schema and a User schema.  Both have their tables and such as you know.  From the limited info I can find so far it appears that if the changes are outside the geodatabase system tables we should be good.   I just saw this in a doc about the upgrade tool and its use but what I gave here is about all i found from ESRI or anybody else which has been frustrating.  

So I really could use the following info still...what things are typically removed?  If I have customization in non-geodatabase system tables am I good to do the upgrade without removing it?  Has anybody gone thru this and can give some examples of what they did?  Is there any ESRI written info that explains  this in more detail?

I understand Marco that I think you and I are seeing that any customizations outside the geodatabase system tables should be good to leave alone as long as the geodatabase system tables are clean.  I just trying to get things as definitive as possible.  I always appreciate any info you can give.

[Asrujit_SenGupta]

Why not restore the entire Oracle DB on a test instance and try to upgrade. Check the issues you encounter and then move ahead accordingly..

[JohnPavek]

Well the item is called out specifically as a check item doing the upgrade.  If this is something important ESRI at least should provide more documentation about it.  Other than the comment in a doc or 2 and the info from the wonderful people in this thread I have no other info, examples, etc. to guide what the issue is.  I plan well so I don't have to worry about things.  This is a private company where time done on things has a distinct value so I have to be extra diligent to make sure time spent is as efficient as possible.  If things weren't as customized as they are (I learned long ago customization can have a steep cost so I avoided it as much as possible) I wouldn't worry that much about it.

But you are right Asrujit and it may come down to that.  I've figured out a lot of things in my past by just trying it :-).  I just wish ESRI wouldn't put something like that up and not give support to it with documentation.  I'll still hope I can get some more info from this thread.  I may have to call ESRI about this.

Thanks Asrujit for your reply!

[MarcoBoeringa]

I second Asrujit SenGupta‌'s reply. Ultimately, if this is a vital system, doing a test run of the upgrade on a secondary instance, is the only really safe way to upgrade.

Nonetheless, if none of your customizations has involved the Geodatabase System tables, which I actually also think quite unlikely, as any such modifications would be a pain to maintain for the developers of that customization as well, then you may actually be safe with upgrading.

The thing is, in order to support new Geodatabase functionality, ESRI has had the need to modify the table structure of the geodatabase system tables in multiple major releases over the years / decades. These could be minor but also major re-structuring with replacement of entire tables / fields.

In order to safely - and automatically - upgrade the geodatabase system tables' schema in such instances, I fully understand it is paramount for ESRI to know the existing table structure and contents. This is why having custom triggers, indexes or other modifications to the geodatabase system tables may become problematic once you attempt to upgrade.

[WillStafford]

In reading this you said SDE schema and User Schema
Major Flags here  Read this

Some clarification on terms/routine regarding user schema SDE in oracle. 
Note:

Beginning with ArcGIS 10.7 and ArcGIS Pro 2.3, you cannot create user-schema geodatabases in Oracle.

That will be the biggest hurdle the "user geodatabases"

My Advice after 30 years in SDE. Make a new box and start migrating everything to a new geodatabase.  You are NOT the only one out there impacted by this.
Plain tables added to the SDE geodatabase are okay to leave. Triggers, procs etc (database stuff) added to the sde geodatabase need to be pulled out and saved to a text files for later import.

Good Luck let us know how it turns out.
Will