if you copy the db from prod to another env and then plug in new appservers, no matter what version of bsa, you will get a new entry in the database for the 'new' appserver you just started. this is not limited to 8.6. that's a separate problem from DR.
for DR - when you upgraded the 8.6 env, were there records in the db already for the DR appservers ? did you run the 'persist' operation on the DR appservers against the live database ? how did you upgrade the DR appservers ?
Thanks for the response. I am aware that a new entry is put in the Database when we move the Prod DB to a Non-Prod DB, however, in the past, after the application server was started it retained all the configurations that were defined for the deployment. Now, in 8.6, it creates a "new" deployment based off of the default deployment, not the "Customized" deployment that we have defined... For Instance, we have a application server defined as a Config and NSH server only.. Now when I start it up after a refresh, its defined as a Config, NSH, and Job server.
The DR environment has a completely separate database that is replicated from Production using Dataguard. All information that is updated in the DR environment is lost once we enable dataguard and the replication starts again.. Since it will be a mirror of Production. So in a sense, copying Prod to Non-Prod and copying Prod to DR are exactly the same.
for the prod -> dev copy - that may have been true - i've never noticed that, but ok. in 8.6 the blasadmin info is stored in the db now, so that's probably why.
for the prod-> dr - i think you will need to have the DR servers persist the configs into the PROD live db so that gets replicated over for your dr event.
i'm not sure if it's possible to pre-create things in the db - i'd open a ticket and we can investigate for both.
I already have a ticket in: (ISS04512083)
Is there a way to mimic what the UPI does during the 8.6 upgrade when it "loads" the Application Server data in the database? There has to be some SQL that can be run to perform the same actions.
The solution you propose for DR will not work in our environment. We cannot have an outage, which is why we use DR when Production will be down. To add the content into Production we would need to bring all application servers down, prod and dr...
yeah - makes sense, will follow up in the ticket for now.