How to migrate user preference in discoverer

[soumya]

Hi,

We are in process to migrate our discoverer from old server to new server.

Source env:
Discoverer ver: 10.1.2.55
os: rhel 5.10


Destination env:
Discoverer ver: 10.1.2.55
os: rhel 7.7


Recently we have cloned our existing source discoverer instance and restored it into new server. We have performed everything as per documentation. We have no issues in connecting the discoverer from frontend using oracle application.

We have around 500+ users who use the discoverer and they have their own preference settings. Now we want to migrate all the users settings in one go into the new server. Could you please share your view  how to achieve this ? we have already copied the files prefes.txt , .reg_key.dc from the source server to new server but its still not working.

Thanks

[ErmanArslansOracleBlog]

reg_key.dc is a good try, as the documentation says :  When an individual user changes a preference, this change is stored in the reg_key.dc file on the Discoverer middle tier.

Did you follow the MOS note -> How To Migrate Discoverer Plus and Viewer User Preferences After Moving from One Server to Another (Doc ID 459508.1) ??

Did you copy the files to the correct locations?

- copy $OLD_ORACLE_HOME_/discoverer/util/pref.txt to $NEW ORACLE_HOME/discoverer/util/pref.txt
- copy $OLD_ORACLE_HOME/discoverer/.reg_key.dc to $NEW_ORACLE_HOME/discoverer/.reg_key.dc

As you may already saw, the reg_key.dc is a hidden file, it has a "." as prefix.. So did you do that copying correctly?

Are you sure that you remove the reg_key.dc file in the new oracle home, before this copying activity?
You can't see the "." hidden files in Linux without using ls -al.. If you use just ls, they wont be shown..

[soumya]

Hi Erman,

As the document mentioned we have already completed all the steps.
prefs.txt and .reg_key.dc file exists in appropriate location where it should be.  But still now we are not able to see the users modified preference settings.

You can check the screenshot where i have circled a value . This value is set on 150 on source server but here its showing 120 which is a default value.

[ErmanArslansOracleBlog]

Okay, then the documentation is wrong..

Do you have a file called migrateprefs.sh anywhere in the new Disco filesystem?
you can check it using find /<disco_installation_dir> -name migrateprefs.sh

If there is a file/script like that, maybe we should use it..
But first, we need to check its contents and understand what it is doing.
Normally, that script should be run during discoverer upgrades.. to migrate user prefs during discoverer upgrades, but maybe the documentation is wrong.. So we should check it.. Please find the file and review the code.

[soumya]

Hi,

while running the below command its getting errored

[discotest@ccuine23 util]$ sh migrateprefs.sh -from 102
Migrating Discoverer User Preferences ...
Migrating the preferences ...
*WARNING*:This might overwrite any already existing Discoverer preferences
Do you want to continue ? (y/n)
y
migrateprefs.sh: line 26: 22672 Aborted                 (core dumped) $ORACLE_HOME/bin/dis51pr -nopause -migrate $@

[discotest@ccuine23 util]$ cat migrateprefs.sh
#!/bin/ksh
#
# Copyright (c) 2002 by Oracle Corporation.  All Rights Reserved
#
#
#
# NAME
#   migrateprefs.sh
# FUNCTION
#   Migrates Discoverer preferences from iAS 1.0.2 to iAS 9i
# NOTES
#   Usage: migrateprefs.sh [-force]
#   if -force is specified then no confirmation is asked.
#
# AUTHOR
#   KrishnaPrakash.Duggaraju
#
# HISTORY
#   kduggara - 18 May 02 - Creation
#

# set the appropriate environment variables
. /backup/discotest1/prod/10gAS/discoverer/discwb.sh

echo Migrating Discoverer User Preferences ...
$ORACLE_HOME/bin/dis51pr -nopause -migrate $@

[ErmanArslansOracleBlog]

As I already said, we first need to check the script..
We need to see the contents of "dis51pr" if it is in a readable format..

[soumya]

Sorry but dis51pr is a binary file.

[ErmanArslansOracleBlog]

Okay..

We have 2 concerns.

1)documentation about disco user preference migration is wrong.. It just doesn't work in your case.
2)We have a migrateprefs.sh which may be a workaround but it can not be used either.

Then, maybe we don't actually have the ability to do this kind of a user pref migration.

Please create a SR on Oracle Support and update me when you have some new action plan.

Thanks

[soumya]

Let me give you an info. We had a situation on our source environment where we upgraded our database and that time same issue arrived. But the support vendor fixed this in a one go. But this was done in the source environment which is running on rhel 5.10. But i am not sure how did they do this.

Since this is an old product, i doubt we would get support from oracle. However we will try it out.

Thanks Erman for all the help you provided.Really appreciate it.

[ErmanArslansOracleBlog]

It is documented in Oracle Support and you said that you did exactly what is documented..

Ok, I will try a little bit more..

Look we have 2 facts ->

*You can change the default preference values that Discoverer end users are presented with by changing the values in the pref.txt file. For the changes to take effect, you must 'apply' the preferences. For more information about changing default preference values

*You can change an individual user's preferences using the Discoverer preferences command line utility. Changes that you make are stored in the reg_key.dc file (for more information about changing individuals users' preferences

Anyways, Did you check the Oracle® Business Intelligence Discoverer Configuration Guide 10g Release 2 (10.1.2.1) ?

I don't know the history of your source instance, so maybe the user prefences were not changed there.. maybe the default values were changed there. I mean maybe the pref.txt in your source was changed and this way you got the user preferences updated in your source..

If thats the case, your focus should be activating the changes in pref.txt in your target env
And if so , you may need to use applypreferences script.

Here is the statement from the Configuration gude;

After editing the pref.txt file, you must run the applypreferences script to
apply the preference changes you have made, then stop and restart the Discoverer
Service .

Also look at the definition of pref.txt  -> This file stores the Discoverer middle tier preferences, and is used to generate the reg_key.dc file. If you manually edit the pref.txt file, you must run the applypreferences script to apply the preference changes you have made, then stop and restart the Discoverer preferences server component.

So running applypreferences script may be a good idea in any case. ( on the target server ofcourse) -- ofcouse backup your reg_dc file before running the script)

[soumya]

Hi Erman,

Let me answer your queries one by one.

Did you check the Oracle® Business Intelligence Discoverer Configuration Guide 10g Release 2 (10.1.2.1) ?

-- Yes we have gone through the document, and applied almost everything that is related to this.

I don't know the history of your source instance, so maybe the user prefences were not changed there.. maybe the default values were changed there. I mean maybe the pref.txt in your source was changed and this way you got the user preferences updated in your source..

--Well we dont know either, since we are new vendor here supporting the customer for this. We dont have insights what exactly happened back there.

If thats the case, your focus should be activating the changes in pref.txt in your target env
And if so , you may need to use applypreferences script.

-- we have already applied the script applyprefence.sh . but  it didnt help.



So running applypreferences script may be a good idea in any case. ( on the target server ofcourse) -- ofcouse backup your reg_dc file before running the script)


-- As i said , we already copied reg_dc from source to target and applied applypreference.sh on target instance.

[ErmanArslansOracleBlog]

What is written in pref.txt.
Can you see the values(changed) user preferences there? I mean, does that pref.txt have those user profiles setting? This will make us understand how you set the user profiles..
This will make us understand whether or not you have used pref.txt to change them.
You have 2 options to change them right?

1)You can change the default preference values that Discoverer end users are presented with by changing the values in the pref.txt file. For the changes to take effect, you must 'apply' the preferences. For more information about changing default preference values

2)You can change an individual user's preferences using the Discoverer preferences command line utility. Changes that you make are stored in the reg_key.dc file (for more information about changing individuals users' preferences

If they are not in pref.txt.. I mean the changed user pref value then you probably changed the user pref values using the 2nd method as described above..
At least we could see that..

Also please check the contents of applyprefence.sh.. What does it to do propogate the changed user pref values.. This may give us some clues to find the real cause.

Note that, I don't have a 10.1.2 Disco environment at the moment, so I can't check this issue in my lab hands-on..

[soumya]

Hi Erman,

Good evening.

We have finally resolved the user preference issue! The user preference was not replicated because of different database sid. The target dataabase which we were connecting is a clone of source database but has a different sid. Now .reg_key_dc file has entry like oracle database sid \ <username>

Source database
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\WebDisco 10\Userpreferences\prodtest\SYSADMIN\Database]

Target database
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\WebDisco 10\User Preferences\prod\SYSADMIN\Database]

Now here if we connect to the source database from the cloned discoverer instance we can see the user's preference correctly. Where as if we connect the target database from target discoverer instance we are not able to see because the reg key has entry which is validated for prod database only not for prodtest.


I thank for heartily for all the help. Keep up the good work.

Regards,

Soumya

[ErmanArslansOracleBlog]

Good :) thanks for sharing your findings. They are valuable as they are not documented.
There maybe a way to modify those records and make them changed acoording to the target database instance..
So what did you do for the solution? Or what are you planning to do?

[soumya]

Actually we are moving out our old discoverer instance into a new hardware. So customer wants to check if everything is working properly from the new hardware, hence we cloned the source discoverer instance into a new one. Now since the database is also going to be cloned into the hardware its going to be same SID as of current one , so naturally from  discoverer end we wont need to change anything.

But i think as a workaround we can simply find and replace inside the reg_key file's  source database name with the target database and save it. This way this should work.

[ErmanArslansOracleBlog]

I see..

Yeah. An update.. that is also what comes to my mind at the moment.

29 Ağu 2020 Cmt 18:37 tarihinde soumya [via Erman Arslan's Oracle Forum] <[hidden email]> şunu yazdı:

Actually we are moving out our old discoverer instance into a new hardware. So customer wants to check if everything is working properly from the new hardware, hence we cloned the source discoverer instance into a new one. Now since the database is also going to be cloned into the hardware its going to be same SID as of current one , so naturally from  discoverer end we wont need to change anything.

But i think as a workaround we can simply find and replace inside the reg_key file's  source database name with the target database and save it. This way this should work.

---

If you reply to this email, your message will be added to the discussion below:

http://erman-arslan-s-oracle-forum.2340467.n4.nabble.com/How-to-migrate-user-preference-in-discoverer-tp8677p8706.html

To start a new topic under Middleware / Weblogic, email [hidden email]
To unsubscribe from Erman Arslan's Oracle Forum, click here.
NAML