Slow check-out in Intralink 3.4

[gchampoux]

One of our smaller assemblies is taking too long to check-out.
It used to take less than 10 seconds, but now it requires 15+ minutes.
If we watch the workspace folder, we see that nothing is happening during the first 15 minutes.
There is no CPU activity. Afterward, the files show up quickly.
We tried checking out the dependent files one at a time to see which one was the culprit.
All of them (including the assembly itself) checked out as quickly/normally.
This "lag time" only occurs when checking out the assembly and dependents together.

Has anyone see this behavior?

Gerry Champoux
Williams International

[JimAugeri]

What is the state (Size?) of the Local.ddb file? (When it gets large, it
slows everything down; try running LDBCOMPACT on it)

What about the Temporary (DBF) tablespace on the Dataserver? (Dataserver
admin will need to look at this.)





--Jim Augeri

MCAD Tool Support - Engineering Quality and Tools (EQT)

Honeywell Aerospace

9201 San Mateo Blvd. (MS B-3)

Albuquerque, NM 87113

Phone - 505.828.5808

Fax - 505.828.5500

james.a.augeri@honeywell.com



This e-mail message and any attachments are for the use of the intended
recipient(s) and may be controlled by U.S. export control laws. Any
unauthorized review, use, disclosure or distribution of this
communication in whole or in part without the express written consent of
Honeywell, or the U.S. Government as required, is prohibited. If you are
not the intended recipient(s), please contact the sender by reply e-mail
and destroy the original message and any copies of the message as well
as any attachment(s) to the original message.

[gchampoux]

A few people have suggested compacting the local.dbb file. This is not where the problem reside.
I should have included more info.
This problem is affecting all users that attempt to check-out this one particular assembly, or any upper-level assembly that contains it.
The slowness happens even if the user has a small local.ddb.
As a test, I deleted my .proi folder, and started fresh.

The check-out was still slow.

[BrianSullivan]

Hello Gerry,

While I would first start with DSMU to confirm the Tablespace are not getting full... ensure you do not have one above 90%... but since it's not all assemblies and only a single assembly...
It sounds like it is an Indexing Error in Oracle. Also increase Temp Table Massively... in Intralink 3.4 it defaults way to small (like 40MB.... I've seen typical checkout needs to use 400MB for a customer so set it higher... that at least might reduce from 15 minutes to something survivable)

When you check out do you see the CPU performance of Oracle on the Server ramp up?

I would suggest that you contact PTC and ask how to "gather statistics" or rebuild the index. (Especially if you had updated Intralink 3.4 M06X with Oracle 10g from the Oracle 9i). Not sure what TPIs tell you the procedure.... PTC would like tell you to run Ilink_Patches first... which could not hurt.

Brian Sullivan

[msteffke]

Perhaps you could boost the size of your temp table space. Some assy's
may need more than others. Strange how its just one assembly.

Mark Steffke
Engineering System Administrator
The Delfield Company
Manitowoc Foodservice
T 989.775.9215
Integrity, Commitment to Stakeholders, and Passion for Excellence

[gchampoux]

Thanks to all. I'm getting lots of good suggestions to try.
Several suggested checking the table spaces, and increasing them if needed.
No need. See below:

Tablespace Total Space Free Space Percent Avail.Blocks

name (Mb) (Mb) Allocated ratio (%)

----------- ----------- ---------- --------- ------------

DEVELOPMENT 150 150 0.0 N/A

PDM_INDEX 4,500 1,723 61.7 8.1

PDM_TABLE 3,375 1,331 60.6 14.4

SYSTEM 525 229 56.4 26.3

TEMP 2,500 2,267 9.3 N/A

UNDOTBS1 2,100 2,074 1.3 N/A

----------- ----------

sum 13,150 7,774

[gchampoux]

Special thanks to Mike Reece who suggested check-out as links instead of a local copy.
When using links, the check-out takes less than 3 seconds, so we are onto something.
The dataserver (Oracle) is probably not where the problem resides, and I should now focus on the fileserver.
Maybe a drive is going bad.

P.S. We are using Intralink 3.4 M030 with WildFire 3 M130.