BORLAND SOFTWARE CORPORATION
Troubleshooting and Addressing Performance and Scalability
Issues in Starteam 2006-2008R2
Kieran Gobey
12/4/2008
Starteam customers have been experiencing performance issues after upgrading from 2005R2. These
issues are generally one of two separate but distinct types, Performance and Memory based Scalability
(i.e. running out of RAM). These issues are rarely related and should be handled differently. However in
some extreme cases customers have reported both issues at the same time. Despite the fact that they
can be seen at the same customer at the same time, they should be treated as separate-but-related
issues.
In this document I will try to show proper troubleshooting techniques to understand the true nature of a
customer’s complaint and how these techniques would direct you to the correct recommendations for
improving the customer’s experience.
BORLAND INTERNAL DOCUMENT
Table of Contents
General Advice .......................................................................................................................................... 3
Investigating Server Performance and Scalability .................................................................................... 4
Your immediate course of action:................................................................................................4
So what can you do for the customer right away? .......................................................................5
Making Changes to the Server XML file ....................................................................................6
Sockets Timeout Minutes Parameter ........................................................................................... 6
Typically recommended settings for IDS Cache 2006 Server........................................................ 6
Memory Maximum Load Percentage ........................................................................................... 7
The recovery interval .................................................................................................................... 7
The recovery cycle parameters ..................................................................................................... 8
IDS Cache for the 2008 and 2008R2 Server .................................................................................. 9
Setting Cache Priorities for Item Types:........................................................................................ 9
Default....................................................................................................................................... 9
Configuring Item Cache Memory Usage for 2008 and 2008R2 .................................................. 10
Advanced Analysis and Troubleshooting ..................................................................................... 11
Clients, SDK’s, Utilities and other Automated Applications ..................................................... 11
API Versions Cheat Sheet ........................................................................................................ 11
MPX and Cache Agent and Automated Applications and Utilities ........................................... 12
Link Implementations and Processes ..................................................................................... 13
Trace Files............................................................................................................................. 13
Long Queue Times................................................................................................................... 13
Long Database times ............................................................................................................... 14
Lots of high CPU times ............................................................................................................ 14
Lots of high Lock times ............................................................................................................ 14
Known Slow Server Commands .............................................................................................. 14
Collecting and Understanding PerfMon Results...................................................................... 16
Once we have PerfMon Results what do we do? ....................................................................... 22
Database Server Tuning ............................................................................................................ 26
Machine Performance ........................................................................................................... 28
Database (DBMS) Configuration ............................................................................................ 29
Oracle: Recommended Initialization Parameters ...................................................................... 29
Data optimization, tuning...................................................................................................... 31
Running SQL Scripts for Microsoft Databases............................................................................. 31
Running SQL Scripts for Oracle Schema Users ............................................................................ 34
Collecting and Understanding Server Statistics for 2008R2 ....................................................... 36
2
BORLAND INTERNAL DOCUMENT
General Advice
When approached by the customer about issues in performance or scalability, you must discover which
one of the two issues the customer is reporting right away. Typically the questions you must discern if
the server is running out of resources (RAM, CPU, Disk Space and Network bandwidth) for both the
Starteam Server and the DBMS Server or if the issues are user based with users reporting slow client-
based functionality.
If the issues are based around the client you will have to find out how widespread this performance
issue is. For instance, are users in one remote office complaining, or are all users Network-near to the
Starteam Server complaining and everyone else is OK? Or… is the performance issue total. There are
many possibilities here and you will need to be very precise about who is reporting the issue.
Immediately collect the Database, Server XML, Administrator user ID and password and start collecting
Trace Files. Collect the OS event and applications log immediately and get Performance Monitor
monitoring Handles, Private Bytes and CPU Time, specific to the StarTeam Server Process so that we can
get information that will help us understand the entire picture as soon as the issue is reported.
There are no “Silver Bullets” for this issue. Every small action will contribute to a more stable and better
performing Starteam Server. To do everything included in this document might be unnecessary, but
doing more than one is almost certainly going to be necessary.
3
BORLAND INTERNAL DOCUMENT
Investigating Server Performance and Scalability
Your immediate course of action:
Collect the regular suspects:
o Starteam Database as a “backup”
o Starteam Server XML file
o Starteam server Event and Application Logs
o Database server Event and Application Logs
o System Information from both machines
To get this information type: msinfo32 from the Windows RUN command line
You can save this as a text file and FTP it with the rest of the information
o Server Logs going back a couple of weeks
o Any Upgrade Logs
o Network topographical information
Are the DB and ST server network-near? How many “hops” etc.
You might have to get the customers IT department involved to get meaningful
answers
o Administrator User ID and Password
o Ascertain whether or not the Starteam Server and the DB Server are running the /3GB
switch in the boot.ini file (collect this file)
Immediately configure the Starteam Server to create Trace Files.
o When setting this up, make sure you are setting the “Trace operations that take at least:
milliseconds” to 0 (zero)
o Leave these to be generated for about a week. We can decide what we want from the
files generated.
o This may take a large amount of space – make sure the customer watches how much is
being used.
If the server has produced Dump files, please make sure to gather these also.
o Always gather the corresponding Server Logs or they will be meaningless.
o If you gather Dump files, it is more important to gather the first Dump file generated
than the last file, but gather all of them when you can.
o Event and Application logs are very important to gather at the same time as dump files.
You can ask a customer to turn on “Dr. Watson” if the server is crashing with
errors, Dr. Watson is not always part of Windows anymore, but can be
downloaded from MS as a utility.
Start the CPC with NetMon and perform a sample of customers normal common day to day
activities in their largest-most commonly used projects.
o Please do this with a known or unique user ID
o Track the day, time and seconds that each activity is performed
We’ll directly compare the results to the Trace Files and to the PerfMon data to
see if we can draw any conclusions from it.
4
BORLAND INTERNAL DOCUMENT
So what can you do for the customer right away?
Open the Task Manager.
1. Ascertain whether the ST and DB servers are running out of RAM
a. How much is in use on the machine as a whole?
b. How much total system RAM is still available?
c. How much System RAM is installed?
d. Is the /3GB switch enabled?
2. Ascertain whether the ST and DB servers are CPU-bound
a. Look at the Task Manager tab that shows CPU activity graphically…
i. Does it look “busy”, i.e. are there any peaks close together at 33% of total
system CPU or higher?
3. Add Handle Count to the listed columns in the Task Manager
a. Do this by going to the “View” menu option and selecting the “Handle Count” option.
From this initial look you will be able to see how much RAM Starteam is using, and what the Handle
Count actually is. You will also be able to tell if the CPU is busy.
RAM should normally on a busy server hover around 500MB to 2GB of RAM
Handles would normally be between 400 and 1000
CPU should be barely moving, a sign of a CPU bound machine is a graphical representation
where the CPU shows very frequent peaks around 33% or higher… this does not seem like it
would impact Starteam or a DBMS Server, but in actuality it is a sign that the CPU is not
powerful enough for the current load that Starteam is exerting
This is section is also covered in “Clients, SDK’s, Utilities and other Automated Applications” later on in
this document.
Another important task to initiate with any customer immediately is to track down all applications and
users running old SDK’s - older than 9.0. The first place to start looking for them is in the Server Log.
Send the server log to CE and ask for it to be parsed to look for old SDK’s. Once you have located these
5
BORLAND INTERNAL DOCUMENT
older CPC’s, Command Lines, Utilities and Scripts they should be updated to the most recent version.
Almost every time this has been carried out for a customer, performance has started to stabilize.
Making Changes to the Server XML file
Sockets Timeout Minutes Parameter
This setting is still implemented in 2006 and beyond and is still effective in stabilizing performance. This
parameter effectively reduces the Handles in use by Starteam Server, if handles seem to steadily climb
without going back down, then introduce this setting. Another reason to include this setting is if Handles
are more than ~900 to ~1200… This isn’t a lot for a Windows application, but it’s possible something
might be leaving sockets open and taking resources from the machine.
We recommend that this be set for between 4 and 16 hours in minutes, i.e. 10 hours = 600 minutes.
Anything more than that and the stabilization effect might take longer to realize, and any shorter and
users might be affected.
This parameter works by dropping apparently abandoned sockets that incorrectly closed user
connections have left behind. Closing those abandoned sockets releases resources back to the machine
and stabilizes the performance of the Starteam server.
Typically recommended settings for IDS Cache 2006 Server
This set up will allow the customer to benefit from IDS caching for CR’s only. The last 5 parameters are a
recommendation we have made to aggressively manage the memory IDS Cache uses. This has proven
very successful when implemented for customers using IDS Caching or not. There was a bug in 2006 that
allowed IDS Cache to be collected even when it was apparently “off”, so the last 5 parameters need to
always be set for 2006 customers.
The following section discusses each of the last 5 settings in detail.
6
BORLAND INTERNAL DOCUMENT
Memory Maximum Load Percentage
The option ItemCacheMemoryLoadMaxPct is another new XML parameter to fine tune. But there are
some starting calculations you must make. To start, you must first understand that the Max Load
Percentage is referring to total System RAM, not just RAM utilized by the Starteam server process.
This setting is calculated with the understanding that the machine must consume a certain percentage
of total system RAM before the IDS Cache Purge should start working to release items from the IDS
cache. For a customer on an 8GB machine typically IDS Purge should kick in when Starteam’s total RAM
used reached about 2GB of RAM. This works out to be about 2.5GB of total system RAM in use as the
Windows-system on this machine would normally use around 500MB when in production. (2GB
Starteam RAM + 500MB of System RAM combined)
The way to work out then what percentage amount to enter is to use this equation.
ItemCacheMemoryLoadMaxPct = (DesiredPhysicalMemoryLoad*100) / TotalPhysicalMemory
i.e. = (2.5GB * 100) / 8GB = 31.5%
Input the 31.5% value into the XML file
On a machine with 4GB of RAM this same 2.5GB of RAM works out to be:
(2.5GB * 100) / 4GB = 62.5%
Note 1: the 2.5GB is only possible on a machine with the /3GB switch enabled in the Boot.ini
Note 2: the default for this value when left blank is 75%. This is OK if the machine is a 2GB machine, but
any more than 2GB of System RAM and this value needs to be worked out via this method.
Note 3: there is no harm setting the desired RAM to a lower value. Anything from 500MB to 2GB is OK as
far as my testing has shown. Anything less than a percentage based on 500MB of total system RAM
seems to be pointless.
The recovery interval
Recovery in this parameter really means “how often to purge the IDS Cache” in seconds. The default
when left blank is 60 seconds.
7
BORLAND INTERNAL DOCUMENT
The most I have seen Starteam grow RAM usage in 60 seconds is 240MB (4MB per second) with
Datamart running. Therefore we suggest when playing it safe on very busy systems to set this interval to
30 seconds, making it more unlikely that the RAM growth-rate will out pace the purge-rate.
There does not seem to be any benefit from setting it to lower than 30 seconds when correctly setting
the Recovery Cycle parameters in concert with this setting.
Recommended:
The recovery cycle parameters
ItemCacheRecoveryCycleMin is the Minimum amount that IDS Purge should try to remove from the IDS
Cache (in Bytes) to try to reach the ItemCacheMemoryLoadMaxPct value specified in the XML file. This
surprisingly can be set to a very large number. By default, this is set to 10MB, but in testing I set it as
high as 250MB with absolutely no ill effects at all.
ItemCacheRecoveryCycleMax is the Maximum amount that IDS Purge should try to remove from the IDS
Cache (in Bytes) to get try to reach the ItemCacheMemoryLoadMaxPct value set in the XML file. This
also can be a very high number; I have set this to 500MB with no problems. But I have also set this to
match the minimum. There were no ill effects by doing this.
ItemCacheRecoveryCycleInc is the amount that the IDS Cache should increase the amount purged over
the minimum amount on each attempt of Purge to reach the ItemCacheMemoryLoadMaxPct value set
in the XML file. In other words, if I set minimum to 50MB and the Max to 500MB and I set the increment
to 250MB, when the ItemCacheMemoryLoadMaxPct value of 31.5% is reached, the first purge will try to
remove 50MB of cache data. If the 31.5% is not reached by purging 50MB, the next time around the
Purge will increment the amount purged by 250MB, therefore attempting to release 300MB.
This will continue to increment each successive time until IDS Purge reaches the maximum of 500MB for
each purge attempt as it tries to reach the 31.5% of total RAM used by Starteam and the system
combined. Think of the increment as something that will kick in when the usage of Starteam suddenly
increases and the normal settings of IDS Cache Purge are overwhelmed. So use the increment to allow
Starteam to catch up with the demand, allow this setting to be very large so that in a short amount of
time when the Starteam server is hit very hard, it can easily and quickly catch up.
In my testing I found that on a very high load system that if you set the Min to 50MB, the Max to 500MB
and the Increment to 250MB at 30 seconds, you will keep the IDS cache in check very easily.
8
BORLAND INTERNAL DOCUMENT
I have also set each Min, Max and Inc to 262144000 (250MB) in testing to keep IDS purge essentially
empty when using a ItemCacheMemoryLoadMaxPct of 10% on a 4GB Server (500MB).
IDS Cache for the 2008 and 2008R2 Server
The following item cache configuration parameters are obsolete in StarTeam Server 2008:
ItemCacheReclamationPeriod
ItemCacheMemoryLoadMaxPct
ItemCacheRecoveryCycleMin
ItemCacheRecoveryCycleMax
ItemCacheRecoveryCycleInc
Setting Cache Priorities for Item Types:
As with 2006 there is a configuration parameter defined for each supported item type, as shown below.
All these parameters take a positive integer value.
ItemCachePriority_Folder – Priority for folder item cache.
ItemCachePriority_File – Priority for file item cache.
ItemCachePriority_Change – Priority for change request item cache.
ItemCachePriority_Topic – Priority for topic item cache.
ItemCachePriority_Task – Priority for task item cache.
ItemCachePriority_Requirement – Priority for Requirement item cache.
Default
Values: 0 for ItemCachePriority_Folder, 100 for the rest of the parameters.
These parameters define the relative preference of the respective item type data in the server cache.
For each type, the server calculates its dedicated share of the overall cache memory, as follows (File
component used as an example):
= (100 * ItemCachePriority_File ) / (ItemCachePriority_File + ItemCachePriority_Cache +
ItemCachePriority_Requirement + ItemCachePriority_Task + ItemCachePriority_Topic +
ItemCachePriority_Folder )
Note: Any unused portion of the type’s share will be distributed among the other item types.
9
BORLAND INTERNAL DOCUMENT
Configuring Item Cache Memory Usage for 2008 and 2008R2
Normally, there is no need to tune the item cache memory usage. However, the Server provides a way
to limit the maximum cache memory size by setting the ItemCacheMemoryLimit configuration file
parameter. This parameter takes a maximum item data cache size in Mega Bytes. The default value for
this parameter is -1, which means that no limit is set.
For a 2008 customer our recommendation is to set this to a limit which keeps the “normal” RAM in use
by Starteam under 2GB.
(Where ### keeps the normal level of RAM for Starteam under 2GB)
10
BORLAND INTERNAL DOCUMENT
Advanced Analysis and Troubleshooting
Clients, SDK’s, Utilities and other Automated Applications
As previously mentioned it’s been proven every time we get a new case for performance and scalability
the most effective action taken is to rid the customers environment of old SDK Jar files. The place to
start hunting for these is in the Server Log.
To make the change to the newer SDK some automated applications will need to be recompiled or even
in extreme cases rewritten. But in most cases replacing the SDK JAR file in use by the utility will be
enough to make it more efficient.
API Versions Cheat Sheet
This is a cheat sheet of API version numbers and their corresponding SDK/CPC versions:
API Version Starteam SDK/Client Version
1.1 5.3.003
1.2 5.3.003
1.3 5.3.003
1.36 5.2.076
1.4 5.3.003
1.5 5.3.033
1.6 5.3.051
1.7 5.3.097
1.8 5.3.125
1.9 5.4
1.10 6.0
1.11 6.0.017
1.12 6.0.029
1.13 6.0.032
1.14 6.0.051
1.15 7.0.001
1.16 7.0.004
1.17 7.0.011
1.18 7.0.043
1.19 7.0.030
1.21 7.0.045
1.22 7.0.056
1.23 7.0.071
1.24 7.0.082
1.25 7.0.115
1.25.1.0 8.0.172.29
11
BORLAND INTERNAL DOCUMENT
1.26 8.5.156
1.27 8.5.187
1.28 8.5.189
1.29 8.5.193
1.30, 1.31, 1.32 9.0
1.33, 1.34, 1.35, 1.36 9.0.10
1.37 9.0.22
1.38 9.0.28
1.39 9.0.36
1.40 9.0.41
1.41 9.0.69
1.42, 1.43 9.0.74
1.44 9.0.96
1.45 9.0.100
1.46 9.0.134
1.47 9.0.135
1.48 9.0.142
1.49 9.0.146
1.50 9.0.155
1.51, 1.52, 1.53 9.0.184
1.54 9.0.196
1.55 9.0.227
1.56 9.5.1.0
1.57, 1.58 9.6.8.0
1.59 10.1.60.0
1.60 10.1.88.0
1.61 10.1.92.0
1.62 10.1.94.0
1.63 10.3.701.0
1.64 10.4.8.31
1.65 10.7.6.0 & 10.7.17.0
MPX and Cache Agent and Automated Applications and Utilities
We have found that Build scripts running against Starteam Server can issue hundreds of thousands of
commands an hour to a Starteam Server. If these build scripts are allowed to perform check outs directly
from the Starteam Server, the load on the server can become too much.
In this situation the only choice the customer has is to update the build scripts with the latest SDK JAR
file and implement Cache Agents to move this load off the server.
For almost every customer, placing a Remote Cache Agent local to the build machine will remove the
load from the Network also. This implementation would demand robust hardware to run the remote
cache agent and the build script at the same time, but nearly all currently available server hardware
would be sufficient to do the job with ease.
12
BORLAND INTERNAL DOCUMENT
Link Implementations and Processes
Links in Starteam are notoriously suspect in cases of poor performing Starteam configurations. You
should immediately start to look at how Links are used and implemented at your customer.
The “big two” Links implementations and processes that can cause Starteam to have issues are:
1. Linking thousands of items to a single file or CR
2. Automated applications creating and looking for Links.
Both of these implementations have proven to cause severe performance issues for customers using
Starteam. Links are scheduled for optimization but this is a long way off at this time.
Trace Files
Long Queue Times
Queue times are actually the server waiting for the database to receive and process the next command
from the Starteam Server. To reduce this you must increase these Server XML parameters: (They replace
pooled connections in 2006 and on.)
You need to make each parameter the same as the others for optimal performance. The default is 0
which is actually interpreted as 5 pooled connections by Starteam Server.
We recommend starting at 24 pooled… After this change, gather new Trace files for each time you
adjust these parameters. The new Trace files should show a decrease in the Queue times. If the queue
times are still around 500 milliseconds (1/2 a second) you should increase this number to 35. Once
readjusted you need to gather more trace files and see if the Queue times have decreased any further.
At some point beyond 40 you will likely see the Queue times increase rather than decrease. You need to
make sure you don’t overload the Database server and cause it to thrash. This will start a performance
to decline. We don’t suggest you go above 40 to rectify poor Queue times. If queue times are still high
after reaching 40 pooled connections you need to look for other causes.
Queue times are ideally 0, but as close to 0 as possible is OK.
13
BORLAND INTERNAL DOCUMENT
Long Database times
Long database times are likely due to poorly performing database server instance or a poorly configured
one. Recently we have encountered two customers whose hardware was not sufficient to handle the
new load that our new transaction implementation places on the DBMS.
You will need to be careful trying to fix this issue as this is not always the same as a high queue time, but
sometimes they can be related. You can have poor database performance without high queue times,
and visa versa.
Database tuning and a study of the Database hardware are you real troubleshooting steps here. A long
database time can be caused by slow CPU, poor Hard disk performance and a lack of RAM on the
Database server. It could also result from thrashing, the DBMS is working too many commands at a time
and nothing is getting completed.
Lots of high CPU times
Lots of time on the CPU means the hardware is not up to the task of running a Starteam database.
Questions to ask…
Is the server running the DBMS for Starteam alone?
Is it shared with others?
Is the hardware sufficiently powerful to run the DBMS for Starteam efficiently?
Lots of high Lock times
Locks indicate that the jobs on the DBMS are not being executed quickly enough. The resolution for this
is to properly configure the DBMS per our recommendations in the Best Practices Guide and the
Installation Guide.
Known Slow Server Commands
PROJ_CMD_LINK_GET_INFO
PROJ_CMD_LINK_CREATE
PROJ_CMD_CATALOG_LOADSET
PROJ_CMD_CATALOG_LOADALL
PROJ_CMD_LABEL_ATTACH_EX
PROJ_CMD_LABEL_GET_PROPERTIES
PROJ_CMD_GET_FOLDERS
PROJ_CMD_GET_FOLDER_ITEMS
PROJ_CMD_REFRESH_ITEMS
FILE_CMD_CHECKOUT
SRVR_CMD_VAULT_PUT
SRVR_CMD_GET_USER_INFO
Note: there are more, but these are common.
14
BORLAND INTERNAL DOCUMENT
Especially if you see these in a very high percentage of these commands be sure that they are being
issued by the latest clients.
If you see a lot of Checkouts and “Vault Puts” make sure your customer implements MPX with Root and
Remote Cache Agents to move this load off the server completely.
Make a note of what commands are slow, look at the possible reasons why… For instance,
FILE_CMD_CHECKOUT (check outs) or SRVR_CMD_VAULT_PUT (check in) might be slow because a
large amount of data is sent to or from the client as “Bytes Sent”, this makes sense, this should result in
a reasonably long “Stream Total Time” also.
But if you’re getting long times on PROJ_CMD_GET_FOLDERS, might indicate that the project is gigantic
– and the “Bytes Sent” would be gigantic also. It may take some thought and analysis to understand why
certain commands would be slow and to find a solution
You will likely need to involve a CE at this point.
15
BORLAND INTERNAL DOCUMENT
Collecting and Understanding PerfMon Results
Control Panel…Administrative Tools…Performance
Right click on the Counter Logs…New Log Settings
Give the log a name
16
BORLAND INTERNAL DOCUMENT
Save the results as a .csv (Comma Separated Values) Text File not a “.blg” (Binary Log).
It’s easier to read and the results can be graphed for clearer understanding.
Add counters
17
BORLAND INTERNAL DOCUMENT
We are checking on the StarTeam Server Process…Private Bytes (or RAM that is being used by the
StarTeam Server Process).
Typically we are most concerned with the following three items:
1. StarTeam Process:
a. StarTeam Server Handle Count
b. StarTeam Server Private Bytes (how much RAM is the StarTeam server using)
o Include StarTeam Server CPU Time when suspect
18
BORLAND INTERNAL DOCUMENT
2. Include Memory “Available MBytes” on the machine
3. Processor Time (Select “_Total” to get total for ALL processors)
19
BORLAND INTERNAL DOCUMENT
Add…then Close
We are now collecting information on
o How much free RAM is available?
o How much RAM StarTeam is using
o Handle count for StarTeam
o The %Processor Time is the percentage of time the processor spends executing non-idle
threads, or how hard the processor is working.
20
BORLAND INTERNAL DOCUMENT
Set interval…
Then set the log file type. If you set text file comma delimited you will have to import into MS Excel or
MS SQL
21
BORLAND INTERNAL DOCUMENT
Then schedule
Once we have PerfMon Results what do we do?
The results should be sent back as a .csv (comma separated values) document. This is easy for us then to
analyze with Excel. If the results are mistakenly sent back in .blg format, please correct the collection
results by the customer, but we can still use the file.
We are able to convert the .blg to a .csv file with this readme from the Silk Team:
http://support.borland.com/kbshow.php?q=30334
Excerpt:
How can I convert a Windows Performance Monitor file from .blg to .csv?
The relog.exe utility, found in the WINDOWS\System32 directory, can create new
performance logs from existing performance logs. To convert a binary PerfMon log to a
CSV file, use the command:
relog logfile.blg -f csv -o logfile.csv
22
BORLAND INTERNAL DOCUMENT
The best way to proceed with the results collected is to graph the information.
In the example below the customer provided “_Total” Private Bytes information and the StaTeam Server
specific private bytes information also.
When looking at the raw data you can’t really see anything, but if you graph that data on a Line Graph
against time, you can easily see that the total RAM used for the machine and the private bytes used by
Starteam have the same pattern of usage.
From this graph you can also easily see that the difference between the processes is about 500MB,
meaning that the machine without Starteam server uses 500MB RAM. This is a lot and we were able to
go back to the customer and recommend that they turn off unessecary applications and services to free
up some system recources.
We did this because as you can see from the chart, at peak usage there was only 370MB of RAM free for
the entire server – not realy enough for an enterprise application.
The other aspect of this chart was that we were able to rule out the possibility that another application
on the machine was using all the system RAM and causing Starteam to crash. The Crash is evident in the
graph as the RAM is dopped to zero. We were able to coroberate this with the server log.
In these graphs below are a before (top) and after (bottom) samples taken for Handles Count.
23
BORLAND INTERNAL DOCUMENT
This PerfMon was taken over several days, and as is evident in the graph that handles increase all the
time, there is almost no time that the handles drop back to a reasonable level. They were slowly robbing
the machine of resources.
In this sample taken just with 24 hours of data, the day after, you can see how was able to control the handles in a way that actually
stabilized performance for the customer.
24
BORLAND INTERNAL DOCUMENT
These 2 graphs are also examples of a before and after image of the Private Bytes for Starteam graphed.
This top graph looks to be calm and steady, but there is a lot of headroom available to the Server that
was not being used. IDS was off for this customer, and though the RAM was well under control they
were reporting terrible performance issues. Especially for CR’s.
We decided to implement IDS Caching for CR’s. The customer was using the /3GB switch and the max
RAM being used was steady at 2GB. So we implemented IDS for CR’s and set up the IDS Purge settings
according to the recommendations in this document. CR performance was dramatically improved and
RAM was maintained at or below a 2.7GB high.
25
BORLAND INTERNAL DOCUMENT
Database Server Tuning
Database Server tuning should be looked at in 3 ways.
Machine performance
Database (DBMS) Configuration
Data optimization, tuning
[First here is some background as an excerpt from Starteam Best Practices]
What is a “Large” Configuration?
The more sophisticated hardware deployments we’ll recommend are those to support a large
configuration.
But what constitutes a “large” configuration?
Many of us at Borland have all StarTeam components deployed on a single machine: a StarTeam server,
an MPX Message Broker and Cache Agent, a workflow Notification Agent, a Borland Search server, and
various StarTeam clients. Moreover, we often run these along side SQL Server, Office, and other tools.
What this should tell you is that StarTeam components use resources proportional to the work they do.
Memory, CPU, and other resources are consumed as the number of users and the volume of
information grow.
There are no hard rules about what makes a StarTeam configuration small, medium, or large. However,
for our purposes, we’ll use these definitions based on concurrent users:
A small configuration is one that supports no more than 50 concurrent users.
A medium configuration is one that supports no more than 100 concurrent users.
A large configuration is one that supports 100 concurrent users or more.
Note that we didn’t say anything about data volume or the type of users: on-line users or bulk
applications. This is because, in our experience, the amount of data managed by a StarTeam
configuration (particularly items) tends to grow proportionally with the number of projects and views,
which grow in proportion to the team size. Moreover, the ratio of on-line users to bulk applications
tends to be roughly the same across organization sizes. The concurrent user count seems to be the best
metric for judging configuration size for purposes of deployment planning. So how big can a
configuration get? To date, we’ve seen single StarTeam instances with over 500 concurrent users, over
10,000 total “defined” users, over 4,000 views, tens of millions of items, and up to a terabyte of vault
data. With continuous hardware advances and software improvements, these limits get pushed every
year.
What Happens When a Configuration Gets “Too Large”?
StarTeam does not place hard limits on any of the factors described so far. Our philosophy (so far) is to
allow you to add as many users, projects, items, etc. as you want, relying on hardware to keep up with
the increase in demand. But realistically, there are limits to what you can do with hardware. There are
costs incurred by increasingly growing configurations, and these costs eventually overtake the
advantages of using a single configuration.
26
BORLAND INTERNAL DOCUMENT
If you are the one charged with capacity planning, we want you to know what happens as configurations
get “really big”. The negative effects you’ll see as a configuration grows are:
• Start-up time: The StarTeam Server process performs certain maintenance tasks when it starts
such as purging aged audit and security records in the database. As the amount of activity and
time between-restarts increases, these tasks increase the start-up time. Also, start-up time is
affected by the number of unique “share trees” due to initial caches built at start-up time. With
well-tuned options, even a large server can start in a few minutes, but it can also take up to 15
minutes or more.
• Memory usage: The StarTeam Server process’s memory usage is affected by several factors such
as the total number of items, the server caching option settings, the number of active sessions
(concurrent users), the number of active views, and the number of command threads required.
Caching options can be used to manage memory usage to a point, but sessions, active views,
and other run-time factors dictate a certain amount of memory usage. On a 32-bit Windows
platform, the StarTeam Server process is limited to 2GB of virtual memory. If you enable 4GT
RAM Tuning19, this limit can be pushed closer to 3GB.
• Command size: Some client requests return a variable response size based on the number of
items requested, the number of users or groups defined, the number of labels owned by a view,
and so forth. Large server configurations can cause certain commands to return large responses,
which take longer to transfer, especially on slower networks. Clients will see this as reduced
performance for certain operations such as opening a project or a custom form. In short, be
aware of these
Deploying Large Configurations
As mentioned before, we consider a “large” configuration one that supports 100 concurrent users or
more during peak periods. For these configurations, you should place the StarTeam Server process on its
own system. The database process should also execute on its own machine. Though not strictly
necessary, the root MPX Message Broker and Cache Agent processes can also benefit by executing on
yet another “MPX” machine. Especially when concurrent users rise to 200, 300, or more, moving the
MPX processes to their own machine can remove network traffic and other resource contention from
the StarTeam Server machine.
The key points of this multiple, large configuration deployment are summarized below:
• The StarTeam Server process for each configuration executes on its own machine. This is
typically a high-end machine with 2 CPUs/2GB of memory for 100-200 concurrent users and 4
CPUs/4GB of memory for 200+ concurrent users. If you expect the user base to grow over time,
we recommend you start with the 4CPU/4GB machine.
[Kieran’s Note: with 2006 this has increased another 1GB of RAM… Starteam in general benefits more
from more RAM than it did with 2005R2 because more of View Member information is cached today. In
the past this was limited to only the “tip” information, today we’re including history. This has severely
27
BORLAND INTERNAL DOCUMENT
affected older customers with older databases. Customers who have very old configurations are
experiencing extremely large memory usage. This could be improved for some with a Purge.]
• The database server executes on its own machine. Multiple StarTeam configurations can share
the same database server. (We’ve seen up to 8 configurations use the same database server
without a performance issue.) Each StarTeam configuration uses its own “schema instance”.
Each StarTeam server machine should have a high-speed (1Gbit) dedicated connection to the
database machine.
• The MPX root Message Broker and root Cache Agents can all execute on a single “MPX
machine”. Each root Cache Agent requires access to the appropriate vault, but a high-speed
dedicated connection is not necessary. File access over the network (e.g., using UNC paths) is
sufficient. Note that if you utilize the workflow Notification Agent, you can put it on the MPX
machine as well.
• A shared storage server such as a SAN server can be used for all StarTeam vaults and database
partitions. Depending on the hardware, an interface (e.g., “host” card) may be needed for each
StarTeam server machine in order to access the SAN.
[End of the excerpt from Best practices]
Machine Performance
The DBMS server should be well maintained. For large implementations, the server should be dedicated
to Starteam where possible. Multiple StarTeam configurations can share the same database server.
(We’ve seen up to 8 configurations use the same database server without a performance issue.) Each
StarTeam configuration uses its own “schema instance”. Each StarTeam server machine should have a
high-speed (1Gbit) dedicated connection to the database machine.
Basic check list:
4GB RAM for the server
Dual Core CPU
Lots of fast disk space
Gigabit connection to the Starteam Server
/3GB switch enabled for the Boot.ini file on the Server
28
BORLAND INTERNAL DOCUMENT
Database (DBMS) Configuration
Oracle: Recommended Initialization Parameters
[As reprinted from the Starteam Installation Guide Appendix]
The following two tables recommend Oracle parameter settings for use with StarTeam databases.
Common Database Configuration Parameters
Parameter Recommended Value
Compatible 10.1.0 (10.2.0 for 10g R2 release)
Cursor_Sharing Similar
Log_checkpoint_interval Greater than the redo log size
Log_checkpoint_timeout 0
Workarea_size_policy Auto
Db_block_size 16284 (16k)
Db_file_multi_block_read_count 16
Optimizer_mode first_rows
Timed_statistics True
Open_cursors 400
Undo_management AUTO
Undo_tablespace
Undo_retention 28800
Process 250
Statistics_level Typical
Database Parameters Based on the Total Memory
Total Recommended Settings
Memory
1GB SGA_TARGET = ((Total Physical Memory * 80%) * 60% (We are assuming that 20% of the total
memory will be used by OS.) (Statistics level should be TYPICAL or ALL.)
LOG_BUFFER = 524288
PGA_AGGREGATE_TARGET = (Total Physical Memory * 80%) * 30% (30% of the Non OS
available memory) (This is the starting value. This may need to be adjusted upwards.)
2GB SGA_TARGET = (Total Physical Memory * 80%) * 60% (We are assuming that 20% of the total
memory will be used by OS,) (Statistics level should be TYPICAL or ALL.)
LOG_BUFFER = 1048576
PGA_AGGREGATE_TARGET = (Total Physical Memory * 80%) * 30% (We are assuming that
20% of the total memory will be used by OS.) (This is the starting value.
This may need to be adjusted upwards.)
29
BORLAND INTERNAL DOCUMENT
4GB SGA_TARGET = (Total Physical Memory * 80%) * 60% (We are assuming that 20% of the total
memory will be used by OS.) (Statistics level should be TYPICAL or ALL.)
LOG_BUFFER = 1048576
PGA_AGGREGATE_TARGET = (Total Physical Memory * 80%) * 30% (We are assuming that
20% of the total memory will be used by OS.) (This is the starting value.
This may need to be adjusted upwards.)
Oracle Database Monitoring and Tuning
The most efficient way to tune your oracle database is to start with the recommended database settings
and monitor the instance using the advisories. In addition to that, Borland recommends the use of
statspack to monitor database performance and identify bottlenecks. A detailed description of statspack
is beyond the scope of this document. Please refer to your Oracle 10g performance tuning guide for
more information.
Locally Managed Tablespaces
Locally managed tablespaces manage their own extents by maintaining a bitmap in each data file. The
bitmap helps to keep track of free or used block status. Every bit in the bitmap maps to a block. Any
changes to extents triggers changes to “data blocks” to reflect the new status. These changes do not
update tables in Oracle's data dictionary. Dictionary managed tablespaces perform multiple updates
generating rollback information. Locally managed tablespaces reduce the contention on data dictionary
tables.
Coalescing is not required with locally managed tablespaces since they automatically track adjacent free
space. A locally managed tablespace can either have uniform extent sizes (UNIFORM) or variable extent
sizes that are determined automatically by the system (AUTOALLOCATE). This decision has to be made
during the tablespace creation.
For system managed extents, the database engine arrives at the optimal size of the extents. For
UNIFORM extents, it is possible to specify the size of extent. The following list summarizes the
advantages of locally managed tablespaces:
Reduced fragmentation
Controlled updates to data dictionary tables
Extent size is controlled by the system
Automatically tracks adjacent free space eliminating the need to coalesce free extents
Reduces contention of data dictionary objects
Avoids recursive space management which can typically occur in dictionary managed
tablespaces.
Automatic Shared Memory Management
Oracle 10g introduced Automatic Shared Memory Management (ASMM) of individual
SGA components like shared pool, java pool, large pool and db cache. You do not need to estimate when
setting the size of SGA components. In fact, there is no need to set any parameters defining SGA size.
All you have to do is to set a new parameter called SGA_TARGET. The parameter SGA_TARGET takes a
value which indicates the maximum size of SGA required for your instance.
30
BORLAND INTERNAL DOCUMENT
Consider that you set SGA_TARGET to say 800MB. This indicates that maximum size to which SGA can
grow is 800MB. All the SGA components like shared pool, buffer cache, large pool, java pool will be
allocated from this 800M maximum SGA. Oracle will automatically calculate the initial size of these
components and resizes it as per the requirement without any manual intervention.
You do not have to explicitly define values for shared pool, buffer cache, large pool and java pool if you
set SGA_TARGET. The SGA_TARGET will be limited by the SGA_MAX_SIZE value. The SGA_MAX_SIZE
cannot be modified dynamically. If SGA_MAX_SIZE is not set, both the parameters have the same value
and it will be not possible to increase the size of SGA_TARGET dynamically.
Automatic Segment Space Management
The Automatic Segment Space Management (ASSM) feature allows Oracle to use bitmaps to manage the
free space within segments. The bitmap describes the status of each data block within a segment with
respect to the amount of space in the block available for inserting rows. The current status of the space
available in a data block is reflected in the bitmap allowing Oracle to manage free space automatically
with ASSM.
ASSM tablespaces automate freelist management and remove the ability to specify PCTUSED, FREELISTS,
and FREELIST GROUPS storage parameters for individual tables and indexes created in ASSM
tablespaces. The values for parameters PCTUSED and FREELISTS are ignored and Oracle automatically
manages the space for these tables and indexes inside the tablespace using bitmaps. PCTFREE can still
be specified and is used with ASSM.
SQL Server: Guidelines for Memory and CPU
SQL Server is able to manage its own memory usage. We suggest that it be allowed to do so, and that no
limits be placed on how much RAM it should use. We do recommend that the machine be enabled for
4GB tuning, with the 3GB switch.
SQL Server can be configured to run on particular CPU’s. As CPU0 is often used by Windows configuring
SQL Server to run on the others can improve performance for this machine – if – the hardware is
sufficiently powerful.
Data optimization, tuning
Running SQL Scripts for Microsoft Databases
StarTeam Server comes with some SQL scripts written specifically for use with the Microsoft SQL Server
and SQL Server Express databases. These scripts help you maintain and tune StarTeam databases. You
run some SQL scripts after installation, some on a weekly basis for database performance maintenance,
and some scripts are run for you automatically by StarTeam Server.
31
BORLAND INTERNAL DOCUMENT
The SQL scripts for Microsoft SQL Server and SQL Server Express databases that you may run are located
in the Borland\StarTeam Server 2008\DBScripts\Sqlserver_Scripts folder.
Note: The Sqlserver_Scripts folder contains several subfolders: Create_Stored_Procedures,
Drop_Stored_Procedures, Install, Preinstall, and DW (for Data Warehouse). The scripts in these
subfolders are run by StarTeam Server as needed. Never execute any of them directly from an external
database user interface, such as SQL Query Editor.
The following table lists the SQL scripts that you are most likely to need. Some should be run manually
on a regular basis. The table recommends the frequency for running these scripts. You may adjust the
frequency depending on the StarTeam usage at your facility. Run scripts at times when the server is least
used, such as overnight or on weekends.
In addition to running these scripts, you should also run a Purge option from the Server Administration
tool to remove deleted views from the database. Borland recommends purging the database after you
have deleted one or more views from a StarTeam project. See the Administering and Using StarTeam
guide for information on the Purge option.
StarTeam Script Name Run Frequency
starteam_sqlserver_dbcc.sql Weekly
starteam_sqlserver_dbcc_reindex.sql Twice a week (minimum)
starteam_sqlserver_dbcc_showcontig.sql Twice a week (minimum)
starteam_sqlserver_dropall.sql Only if necessary
Cautions
Before running any of the StarTeam SQL scripts for a Microsoft SQL Server or SQL Server Express
database, ensure that the database compatibility mode is set correctly. For Microsoft SQL Server 2005-
based configurations, set the database compatibility mode to 90.
Be sure to backup your StarTeam database, as necessary, and verify these backups periodically. You
should restore and test backups of your StarTeam project data on a test system. Restoring and testing
your backups helps to ensure that your data is being backed up correctly.
To run a script for a Microsoft SQL Server or SQL Server Express database:
1. Install SQL Server Management Studio or SQL Server Management Studio Express from
Microsoft
2. Choose Start > Microsoft SQL Server [or Microsoft SQL Server Express] > SQL Server Manager
Studio [or SQL Server Manager Studio Express].
3. Design a new query or open an existing one in SQL Server Manager Studio.
4. Choose Query > Connection > Connect to connect to the server that contains the StarTeam
database you want to access.
5. Select the appropriate StarTeam database.
6. Open the tuning script, by choosing File > Open > foldername\scriptname
7. Execute the script, by clicking the Execute button on the toolbar or pressing F5
SQL Scripts for Microsoft SQL Server and SSE Databases
starteam_sqlserver_create_check_database.sql
32
BORLAND INTERNAL DOCUMENT
o Run: automatically by StarTeam Server when appropriate.
starteam_sqlserver_create_database.sql
o Run: automatically by StarTeam Server when creating a new server configuration.
o This script creates a new Microsoft SQL Server database.
starteam_sqlserver_create_upgrade_34.sql
o Run: automatically by StarTeam Server when upgrading a server configuration.
starteam_sqlserver_create_upgrade_36.sql
o Run: automatically by StarTeam Server when upgrading a server configuration.
starteam_sqlserver_create_upgrade_55.sql
o Run: automatically by StarTeam Server when upgrading a server configuration.
starteam_sqlserver_create_upgrade_58.sql
o Run: automatically by StarTeam Server when upgrading a server configuration.
starteam_sqlserver_dbcc.sql
o Run: weekly.
o The starteam_sqlserver_dbcc.sql script rebuilds the database indexes and performs a
consistency check on the database objects. This script builds the indexes and updates the
statistics in the database distribution pages.
starteam_sqlserver_dbcc_reindex.sql
o Run: at least twice a week.
o This script rebuilds all the indexes in the database. It is extremely important to run this
script from time to time.
starteam_sqlserver_dbcc_showcontig.sql
o Run: at least twice a week.
o This script gives information on database fragmentation.
starteam_sqlserver_dropall.sql
o Run: only if necessary.
o Caution:
Running the starteam_sqlserver_dropall.sql script will delete all StarTeam tables
and the data they contain from the database. Use this script with extreme caution.
The starteam_sqlserver_dropall.sql script removes all StarTeam tables from the database. For
example, if you migrate a StarTeam server configuration to another database, you might use
starteam_sqlserver_dropall.sql to remove tables from the original database. Or if you mistakenly
add the StarTeam tables to a tablespace other than the StarTeam tablespace, use this script to
remove them.
starteam_sqlserver_get_dbinfo.sql
o Run: automatically by StarTeam Server when appropriate.
starteam_sqlserver_get_dbpath.sql
o Run: automatically by StarTeam Server when appropriate.
starteam_sqlserver_run_msde_backup.sql
o Run: after you customize this sample script for your specific environment, it can be run
when needed.
This sample script illustrates how to make a backup copy of a SQL Server Express database. Before
you can run this script, you must customize it for your specific environment. (Be sure to lock or shut
down StarTeam Server before backing up its database.)
starteam_sqlserver_update_statistics.sql
33
BORLAND INTERNAL DOCUMENT
o Run: only if necessary.
o This script updates the statistics about the distribution of key values in each index, which
SQL Server uses to optimize query processing. You do not need to run this script if you have
enabled automatic statistics (using sp_autostats), or if you are regularly rebuilding the
indexes (by running the starteam_sqlserver_dbcc.sql or the
starteam_sqlserver_dbcc_reindex.sql scripts).
Running SQL Scripts for Oracle Schema Users
[As reprinted from the Starteam Installation Guide Appendix]
StarTeam Server comes with some SQL scripts written specifically for use with Oracle schema users.
These scripts help you maintain and tune a StarTeam database. You run some SQL scripts after
installation, some on a weekly basis for database performance maintenance, and some scripts are run
for you automatically by StarTeam Server.
The SQL scripts for Oracle schema users that you may run are located in the Borland\StarTeam Server
2008\DBScripts\Oracle_Scripts folder.
Note The Oracle_Scripts folder contains several subfolders: Create_Stored_Procedures,
Drop_Stored_Procedures, Install, Preinstall, and DW (for Data Warehouse). The scripts in these
subfolders are run by StarTeam Server as needed. Never execute any of them directly from an external
database user interface, such as SQL*Plus or SQL *Worksheet.
The following table lists the SQL scripts that you should run manually and recommends the frequency
for running these scripts. You may adjust the frequency depending on the StarTeam usage at your
facility. Run script at times when the server is least used, such as overnight or on weekends.
In addition to running these scripts, you should also run the Purge option from the Server
Administration tool to remove deleted views from the schema user. Borland recommends purging the
schema user after you have deleted one or more views from a StarTeam project. See the Administering
and Using StarTeam guide for more information on the Purge option.
StarTeam Script Name Run Frequency
starteam_oracle_compute_stats.sql Run weekly
starteam_oracle_database_analyze.sql Run weekly
starteam_oracle_dropall.sql Run only if necessary
starteam_oracle_performance_indic.sql Run as needed
starteam_oracle_rebuild_indexes.sql Run weekly
For a description of these scripts, see “StarTeam SQL Scripts for Oracle Schema Users” on page 97. For
instructions on running Oracle scripts in SQL*Plus, see “To run a SQL script for Oracle schema users:”
below.
Caution
34
BORLAND INTERNAL DOCUMENT
Be sure to backup your StarTeam schema user, as necessary, and verify these backups periodically. You
should restore and test backups of your StarTeam project data on a test system. Restoring and testing
your backups helps to ensure that your data is being backed up correctly.
To run a SQL script for Oracle schema users:
1. Go to the command prompt.
2. Change directories to the directory containing the StarTeam SQL scripts for Oracle schema
users.
3. At the command prompt, enter the following:
sqlplus username/password@servicename where username is the StarTeam Oracle Schema User
Name password is the StarTeam Oracle Schema Password servicename is the Net Service Name
created using Oracle Net 8 Easy Config
4. Execute the script. For example, to execute the starteam_oracle_database_analyze.sql script,
enter @starteam_oracle_database_analyze.sql and press Enter.
StarTeam SQL Scripts for Oracle Schema Users
starteam_oracle_compute_stats.sql
o Run: weekly
The starteam_oracle_compute_stats.sql script updates the statistics in the database distribution page
for all tables in the database. This data enables the query optimizer to choose the right index for a given
query.
starteam_oracle_create_check_database.sql
o Run: automatically by StarTeam Server when appropriate
starteam_oracle_create_check_privileges.sql
o Run: automatically by StarTeam Server when appropriate
starteam_oracle_create_database.sql
o Run: automatically by StarTeam Server when creating a new configuration
This script creates a new Oracle schema user.
starteam_oracle_create_fix_custom_fields.sql
o Run: automatically by StarTeam Server when appropriate
starteam_oracle_create_upgrade_33.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_create_upgrade_34.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_create_upgrade_35_catalog.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_create_upgrade_35_data.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_create_upgrade_36.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_create_upgrade_55.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_create_upgrade_58.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_database_analyze.sql
35
BORLAND INTERNAL DOCUMENT
o Run: weekly
starteam_oracle_create_fix_dup_login_names.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_extract_ddl.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_fix_long_raw.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
starteam_oracle_nextextents.sql
o Run: automatically by StarTeam Server when upgrading a server configuration
The starteam_oracle_database_analyze.sql script detects database corruptions, such as bad blocks or
bad structures in the database. Run this script once a week to gather database information and help
track problems.
This script requires you to connect as the sysdba user, not the user-created schema user.
starteam_oracle_dropall.sql
o Run: only if necessary
o Caution
Running the starteam_oracle_dropall.sql script will delete all StarTeam tables and
the data they contain from the database. Use this script with extreme caution.
The starteam_oracle_dropall.sql script removes all StarTeam tables from the database. For example, if
you migrate a StarTeam server configuration to another database, you might use
starteam_oracle_dropall.sql to remove tables from the original database. Or if you mistakenly add the
StarTeam tables to a tablespace other than the StarTeam tablespace, use the
starteam_oracle_dropall.sql script to remove them. This script can be executed from either Sql*Plus or
SQL*Worksheet.
starteam_oracle_get_dbinfo.sql
o Run: automatically by StarTeam Server when appropriate
starteam_oracle_performance_indic.sql
o Run: as needed
This script enables you to get information about buffer hit ratio, data dictionary hit ratio, library cache
miss ratio, library cache hit ratio, rollback segment information, and hit ratio for all the users.
starteam_oracle_rebuild_indexes.sql
o Run: weekly
The starteam_oracle_rebuild_indexes.sql script rebuilds the database indexes and configures the
storage parameters for the index tablespace. The script assumes that the indexes are located in a
tablespace named INDX. If your index tablespace uses a different name, edit
starteam_oracle_rebuild_indexes.sql to reflect the correct tablespace name. Run the
starteam_oracle_rebuild_indexes.sql script weekly to enhance database data retrieval.
Collecting and Understanding Server Statistics for 2008R2
Starteam 2008R2 introduces a terrific new tool for understanding the Starteam Server. Server Statistics
is available on the Starteam Administration Tool and is enabled via the “Configure Server” tool on the
“Diagnostics” tab.
36
BORLAND INTERNAL DOCUMENT
Pictured here:
Currently we recommend that you set this to no more frequently than 5 minutes.
This will create a new directory for you in the Starteam repository called “Diagnostics”
37
BORLAND INTERNAL DOCUMENT
Under here are a few other directories where the raw data is captured in XML files. Drill down to the
?:\?\Repository\Diagnostics\ServerStatisticsMonitoring folder and launch the
ServerStatisticsMonitoring.html file.
It will look like this once launched. There is a lot of very useful data.
One of the most useful aspects of it will be using it to understand what part of RAM is used by what
cache in Starteam.
Most of this tool has not been used yet, we’ll be learning a lot from this I think.
When sending this to CE, please zip up the entire “#:\?\Repository\Diagnostics\” folder tree and send it
to us..
38