To reduce performance problems over our WAN, we are using Oracle snapshots to put copies of the security domain on DB servers closer to remote end users. While Developers and Supervisors are not able to use this mechanism because the snapshots are not updatable, login time for users has been greatly reduced. One side effect exists however. Because they do not have access to update the repository, they cannot change their passwords. (BTW: It is OK that they can’t send to Repository, DocAgent, etc.).
One way to overcome this is to drop the snapshot on the OBJ_M_ACTOR table where the password is stored and use the table in the original security domain. I have completed this modification in a test environment and everything appears to be working correctly.
Can anyone think of any concerns with this approach? It does not appear that any other tables are affected when modifying the password. I have not determined yet what this does to login response time but that will be the next step.
Perhaps dropping your snapshop on OBJ_M_MAGICID too might open up more possibilities… more likely more problems but as you’re staying read-only it may not hurt. It may just help to keep your security hanging together better.
Anybody else got any thoughts on what might happen?
From: Ralph E Forey Iii[SMTP:FOREY_RALPH_E_III@LILLY.COM] Sent: 17 July 1998 18:50
Listers,
To reduce performance problems over our WAN, we are using Oracle snapshots to put copies of the security domain on DB servers closer to remote end users. While Developers and Supervisors are not able to use this mechanism because the snapshots are not updatable, login time for users has been greatly reduced. One side effect exists however. Because they do not have access to update the repository, they cannot change their passwords. (BTW: It is OK that they can’t send to Repository, DocAgent, etc.).
One way to overcome this is to drop the snapshot on the OBJ_M_ACTOR table where the password is stored and use the table in the original security domain. I have completed this modification in a test environment and everything appears to be working correctly.
Can anyone think of any concerns with this approach? It does not appear that any other tables are affected when modifying the password. I have not determined yet what this does to login response time but that will be the next
step.