UCF is not obeying the proxy configuration

Why might UCF not obey the Proxy Configuration Settings "

There is an undocumented setting called ignoreProxy that can be added to ucf.installer.config.xml configuration file located in the applications wdk/contentXfer directory on the application server machine which will cause the UCF runtime to ignore the proxy settings.

The standard ucf.installer.config.xml configuration file would look something like the following example.

<xml version="1.0" encoding="UTF-8">
<dctm fileVersion="5.3.0.1" compatibilityVersion="5.3.0.1">
<ucfInstaller codebase="" loggerLevel="INFO">

With the ignoreProxy setting it look like the following

<xml version="1.0" encoding="UTF-8">
<dctm fileVersion="5.3.0.1" compatibilityVersion="5.3.0.1">
<ucfInstaller codebase="" loggerLevel="INFO" ignoreProxy="true">

With this setting configured you would see something like the following output to the Java Console when the UCF runtime is being launched.

WARNING: Not looking up any proxy information as it's explicitly configured to be ignored

When this message is displayed the Proxy Configuration will be ignored and you may encounter undesirable behaviour.

This setting is not documented in our Product Documentation currently but some customers have added this setting as it is recommend to add the settings for loadrunner testing. ( See the LoadRunner Scripts for Webtop documentation that can be found on the Documentum Developer Website )

Reference: powerlink

Inbox, Work Queue Monitoring pages are too slow...Optimize Oracle DB

 Add the following settings in init.ora

cursor_sharing = FORCE
optimizer_mode = CHOOSE
optimizer_index_cost_adj = 5
optimizer_index_caching = 95

cursor_sharing = FORCE

This parameter allows the optimizer to recognize similar statements and reduce parsing, even when bind variables are not being used. It
provides best benefit in large load environments. Note, however, that in Oracle 8i cursor_sharing=FORCE could lead to some sub-optimal query execution plans.

optimizer_mode = CHOOSE

This defines the behaviour of the optimizer. When set to CHOOSE, the optimizer will use cost-based optimization if statistics are available, and rule-based when statistics are not available. As certain applications and/or releases provide better performance in rule vs. cost-based optimization, this value provides the greatest flexibility as statistics need only be updated or deleted to switch optimization modes, without having to restart the instance.

optimizer_index_cost_adj = 5

The parameter tells Oracle's optimizer to always make indexes cheaper than full table scans. The default for this parameter is 100, and by changing it to 5, indexes look a lot cheaper to Oracle, and nested loop operations will be favoured.

optimizer_index_caching = 95

The parameter tells Oracle's optimizer to assume that it can expect to find a certain percentage of index blocks in the buffer cache. The default for this parameter is 0, and by changing it to 95, indexes look a lot cheaper to Oracle, and nested loop operations will be favoured.

Courtesy: powerlink.emc.com

Internal Server Error due to timeout from HTTP Server

We are getting internal server error  because of the timeout from HTTP server. Though we have the 'ServerIOTimeout' to '0'(no timeout) from default 60 sec, people told that increasing this timeout will cause hung threads on app server and the app server will take more time to render and JVM will get hung.

Recommendation from EMC for this parameter : 

Increase the HTTP server session value to 300. This should help with the application loading on the client’s web browser.

Following is the ennvironment:
Webtop v6.5
Websphere 7.0

If Workflow queue items are deleted, workflow dars are not getting installed

Here are the two options.

1.       Restore the dmi_queue_item_s table.
2.       All running workflows are useless without the queue item. You will never be able to reach them again. If this is fine we can remove the relationship between the workflows and their queue_items and you can uninstall the wf template again. These workflows should be terminated afterwards to remove them from the system.
a.       Run this SQL query to remove the relationship
update dmi_workitem_s set r_queue_item_id = '0000000000000000' where r_queue_item_id <> '0000000000000000' and r_queue_item_id not in (select r_object_id from dmi_queue_item_s)
b.      The workflow templates can now be uninstalled.
c.       Clean up the repository by terminating all the workflows that are missing dmi_queue_items.

It is not recommended to delete rows from the database that Documentum uses. If you need to delete something, do it through Documentum Administrator or DFC.