cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

long checkout times

Newbie

long checkout times

Datamgr's:

The assem's we build here are getting larger. The largest so far is about
3000 objects. It's reasonable to expect that with the more objects in an
assem, the longer the checkout will take. It now takes about 90 minutes
for the server to check out everything in the 3000 part assem and the user
complains. I've watched the server during his checkouts, and one cpu is
pegged at 100% with his oracle process. There's no other unnecessary
activity or processes running on the server and watched the server i/o's -
nothing seems out of the ordinary and all other porcesses are responsive
during checkout. I'm suspecting the server just doesn't have the
horsepower anymore. There's a TPI 110929 at PTC support that talks about
tweaking db performance - would a tweak like like make much of a
difference?

Snippet of TPI 110929:

optimizer_mode = RULE
to
optimizer_mode = CHOOSE

(*Update* Tech Support has received customer feedback from several sites
that reported additional performance gains for their extra large
assemblies with 1000+ components when the following 2 optimization
parameters and assigned values are also added. The assigned values may be
modified for varying results, please refer to Oracle Documentation for
further guidance).

optimizer_index_caching = 99
optimizer_index_cost_adj = 10

Step 2. Start SVRMGR, connect internally and analyze your PDM schema like:

SVRMGR> connect internal -- Note: NT admins usually must
connect as internal/internal
SVRMGR> execute dbms_utility.analyze_schema('PDM','COMPUTE');
Statement processed.


Here's our environment:

Intralink 3.3 2003290 & Wildfire 2003451
Clients - 3ghz, 1G and 2G mem, XP Pro
Intralink server, db & file - Sun e250 dual 400mhz, 1G mem

/db2 is a vault set to read-only

More server info:

Sun Microsystems Inc. SunOS 5.7 Generic October
1998

Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s0 248287 102658 120801 46% /
/dev/dsk/c0t0d0s6 2056211 984502 1010023 50% /usr
/dev/dsk/c0t0d0s7 14569147 4945104 9478352 35% /home
/dev/dsk/c0t8d0s7 35007716 15696416 18961223 46% /vaults/v1
/dev/dsk/c0t9d0s7 35007716 31432139 3225500 91% /db2
/dev/dsk/c0t12d0s2 35321458 1892934 33075310 6% /vaults/v2

Free Space in Data Base "ILNK" on host "pdm"

Tablespace Total Space Free Space Percent Avail.Blocks
name (Mb) (Mb) Allocated ratio (%)
----------- ----------- ---------- --------- ------------
DEVELOPMENT 20 20 0.00 N/A
PDM_INDEX 560 239 57.00 23.00
PDM_TABLE 630 365 42.00 28.00
RBS 312 235 25.00 N/A
SYSTEM 348 301 14.00 9.00
TEMP 60 11 82.00 N/A
----------- ----------
sum 1,930 1,171


1 REPLY 1

Re: long checkout times

Answers to some questions sent to me so far:

Network infrastructure - server @100Mb FD to router to 1Gb fiber to closet
switch to client at 100Mb FD. Switch and router statistics show zero
collisions/errors. The infrastructure is pretty robust!
Network on the client - A few moments after the checkout button is pushed
on the client, client cpu & network activity drops to nil. Client is
basically doing nothing but waiting.
Network on server - Same as the client, practically nil activity.
Vaults - all local disks on the server, nothing replicated.

Using iostat on the server, I watched disk actvity & could tell that at
the end of checkout transaction, it takes about 100 seconds or less to
actually transfer the files to the client. Fits in with the above info -
doesn't seem to be a networking issue.

Are there any sql scripts/utils that can be used to analyze or test what's
going on inside oracle? Any Solaris 7 patches/tweaks? (other than the list
required by PTC which I already have in place)

Here's the $ORACLE_HOME/dbs/initilnk.ora file. Perhaps something in here
needs adjustment?

# Dataserver DB initialization file. Made upon
# migration procedure from Pro/Intralink v1.3 to v2.0.
# Old value remained in commets just for
# information and verification.
#
always_anti_join = NESTED_LOOPS
audit_trail = NONE
background_dump_dest =
/home/ptc/oracle/dataserver/oracle/rdbms/log #
/home/ptc/oracle/dataserver/oracle/rdbms/log
compatible = 8.1.6.0.0
control_files =
(/home/ptc/oracle/dataserver/dbs/ctrl1_ilnk.ctl) #
/home/ptc/oracle/dataserver/dbs/ctrl1_ilnk.ctl
db_block_buffers = 4800
db_block_size = 4096
db_file_multiblock_read_count = 16
db_files = 48
db_name = ilnk # ilnk
global_names = FALSE
job_queue_processes = 3
log_buffer = 1048576
log_checkpoint_interval = 40960
log_checkpoint_timeout = 1800
max_dump_file_size = 10240
mts_service = ilnk
open_cursors = 350
optimizer_mode = RULE
processes = 100
rollback_segments = (R01, R02, R03, R04, R05, R06,
R07) # R01, R02, R03, R04, R05, R06,
R07
shared_pool_size = 40000000
sort_area_retained_size = 65536
sort_area_size = 1048576
transaction_auditing = FALSE
transactions_per_rollback_segment = 1
user_dump_dest =
/home/ptc/oracle/dataserver/oracle/rdbms/log #
/home/ptc/oracle/dataserver/oracle/rdbms/log
remote_login_passwordfile = EXCLUSIVE # Old value was: EXCLUSIVE