E9.2 Data Dictionary redeploy over Enterprise Servers

[jvalentine]

Is there any inherit risk around redeploying the data dictionary across the Enterprise Servers. We have added row security to a couple of data dictionary items which requires the redeploy to take affect. There is some concern that issues could arise if there where other changes to the data dictionary that we are not aware of. Is there a way to identify changes to the data dictionary that have not been deployed?

Thanks

 

[MFreitag]

Now that's a concern i haven't heard before - never stop learning, eh?
If you're not auditing your DD tables, there's no way (known to me) to find changes in your DD.

What do you mean by "redeploying the data dictionary" anyway - like, what is it you're doing?
If you changed a DD item, e.g. for the row sec. option, you could just deploy the/a table that it includes and that will trigger the regenration of the data item.

 

[markdcci]

Is there any inherit risk around redeploying the data dictionary across the Enterprise Servers. We have added row security to a couple of data dictionary items which requires the redeploy to take affect. There is some concern that issues could arise if there where other changes to the data dictionary that we are not aware of. Is there a way to identify changes to the data dictionary that have not been deployed?

Thanks

jvalentine,
As MFreitag notes, deploying data dictionary changes is not like deploying app/ube/table changes but there are ways to force it. I would be interested to hear your response to his question about what your process is for redeploying data dictionary items.

However, if you aren't sure there are other undocumented or unwanted changes in your data dictionary you might be sitting on a time bomb. In my experience, particularly with AS/400/IBM i, we have had to delete data dictionary runtime specs in the past for troubleshooting/issue resolution. Oracle considers these files (dddict/ddtext) as temporary files that can be deleted and allowed to build again on the fly. If you have something unexpected waiting in the F92* tables it could manifest at that time, just when you're trying to troubleshoot something else.

Also, a full package deletes the dd runtime specs so your next full package would do that anyway.

Perhaps you could query the data dictionary tables for last user and last updated date and time? If you don't have your data dictionary changes locked down to your CNC(s), you could look for the developers' user IDs or something similar. ESUs might have updates in the tables but they will likely be user IDs that you don't recognize so you could filter those out as legitimate (hopefully).

Then I would recommend implementing a controlled process for data dictionary changes going forward.

 

[peterbruce]

Hi JValentine,

@MFreitag and @markdcci have made some excellent comments.

I'm curious about your answer to @MFreitag's question too. The answer would probably help us provide assistance:

What do you mean by "redeploying the data dictionary" anyway - like, what is it you're doing?

Information that would probably help us provide assistance:

• Why row security requires the redeploy of the data dictionary (this will probably depend on the definition of DD redeployment)?
• Could this be related to the possibility of the DD tables being boot tables (planner environment on the deployment server I think) (I don't know if they are. You may have to contact Oracle about this)?
• Do you have separate DD tables for production and non-production (this could make things a lot easier) (This was the case where I worked)?

This post (and others in the same thread for context) may be helpful: https://www.jdelist.com/community/threads/dd-changes-not-reflecting-in-application.56597/post-198466

There may be a possibility that the unknown changes have already been "deployed". In which case things could be a lot more complicated, especially if you need to remove any of the unknown changes. If they impact the changes you have made things could get interesting, and your testing may not have identified this if you didn't know what to test.

If the number of people who have access and knowledge to make changes to the DD is small, it might be an option to informally ask them individually. They may have personal documentation of changes they have made.

A rather long-winded option to find DD changes of which you are not aware requires the changes of which you are aware have been documented. Compare your current DD tables with the original DD tables supplied by Oracle. This could be shortened if you have backups of your DD tables from an acceptable/appropriate time.

I'm not sure how, but backups of the dddict and ddtext temporary files may help.

An Important Consideration
If any DD tables involved in any changes are considered "system" tables, and if row security is considered a "modification," you may have a completely different set of problems on your hands as "system" tables should not be "modified" (see https://www.jdelist.com/community/threads/print-immediate.31224/post-174531 ). You would have to contact Oracle about this.

For The Future
This a side point and not important to your current question/problem, but it could prevent a recurrence: I'm a bit surprised at the possibility of unknown data dictionary changes. I echo @markdcci's recommendation to implement a controlled process for data dictionary changes going forward. I was a one-man jack-of-all-JDE-trades before I retired and I had change management processes I had to follow for all changes I made to the production system, not just the DD.

 

[TFZ]

I will say that with UN6 / UN7 / UN8, there were DD changes around LMASK that I notify all my customers about (especially in place from systems out of date). As, in most cases, customers have a single DD, all change hits everywhere. I have seen where if this warning is not issued / necessary steps taken - people get very, very cranky when suddenly bank account data that should be masked that wasn't masked... is suddenly masked mysteriously a few weeks later in Prod when the ASU hasn't made it there yet.