NX – Upgrading and ugmanager_refile

Some Ideas to Manage the Basic Risks!

Sometimes during a NX version upgrade it is necessary to update the parts in the database as
well using the ugmanager_refile utility. This utility offers a number of useful options but this
article will concentrate on some basic steps of the process design.
Why do you refile?
There are some reasons for re-filing:
• Improved new version performance
! NX does not need to convert every part on load
• The possibility to generate new database objects for all datasets
! NX does not need to generate it during save
! Easily applied to released objects
• The structures in NX and Teamcenter are synchronized
• Loaded parts will not be marked as modified
• Drawings are updated
• Refile heightens database quality because of problem part identification during
process execution
What are the risks?
The process will not be successful for all parts. The target is to get less than 1-2 percent failed
parts in the automatic run.
Refile requires time for preparation and execution as well as skilled administrators if the team has
to finish it successfully within the given time frame.
How do I design the process to reduce the failure rate?
Preparing the refile is the absolute key. Of course, it also depends on the quality of data, but
there are several process parameters that can be very useful.
A very good method is to test the concept against a test database, a mirror of the production
database or a part of it.
The database and the production do not have to be stopped during the refile process, and the
administrator can do it step by step over several weeks.
Ideally, it is much better to stop working on Friday and start on Monday with the new NX version
and the refiled parts. It will require about 48 hours for backup, upgrading, refiling and testing.
How do I make sure the job is done in time?
• Measure the speed
• Define the quantity of targets
• Determine the needed hardware resources
• Define a strategy for the refile itself
! Define the order of refile
! Define jobs using input lists
! Develop a load balancing strategy
• Handling the errors
! Measure the failure rate
! Define actions to fix the problems
! Refile the failed again
How do I measure the refile speed?
Create a test database on your production server(s) and put about 1000 ordinary files from the
production volume on to it. It is better not to use a special test environment, because it will be
necessary to test the refile speed.
Now refile the 1000 parts using the selected refile options and measure the time, for instance, 1.5
hours. From that you can estimate that for a database with about 100,000 similar parts it will take
150 hours. This value is only an estimate and depends on the selected parts.
Define the quantity of targets
Do you need all data in the new NX Version?
Some parts can be excluded, for example:
• Marked for archive parts
• Imported replica parts from other sites
• Parts from other CAD systems
Determine the needed hardware resources
Volume Server:
Additional resources are needed on the Volume Server. Each refiled dataset will get a new
dataset version. How much additional disk space is needed depends on the version limit and the
number of existing versions. A typical case scenario is imported standard parts with one version
and a version limit of 3. A refile doubles the amount of space, but it can be purged later.
If the –k switch is not set, the used user volume needs additional space to store all new dataset
versions.
Determine the number of clients:
Do not refile on the server directly, use clients instead.
To complete the upgrade job in 48 hours, there will be 24 hours for refiling and another 24 hours
for backup, installing, testing, etc. In our example the speed is 1000 parts in 1.5 hours => 150
hours.
Reduce the time and use several clients:
• 150 hours per computer / 24 hours = 6.25 = 7 clients
Select the 7 clients with the highest network transfer rate to the volume server.
Define a strategy for the refile itself
Define the order of refile:
To optimize the process it is useful to optimize the order of refiling for risk management. Refile
the high impact parts first.
Example:
• Standard Parts
• Working parts
• Frequently used parts
• Working assemblies
• Frequently used assemblies
• All other parts.
The sum of all parts in the first 5 categories is limited compared to the total number of parts in the
database.
This order minimizes the risk. If there is a problem during the weekend and the refile stops after
“Frequently used assemblies” the user impact is low.
Define jobs using input lists:
The –I command line option is used to access input lists for the ugmanager_refile utility. There
are two formats available. The advantage of the format @DB/ItemId/RevID is that the
administrator easy controls the current situation.
The next step is to split the parts in several lists, each containing 50 to 500 items.
Because it is time consuming to start the ugmanager_refile program for each item, there is an
option –I for input list. It’s faster to use a long input list but if a corrupt part produces an internal
error the refile for the next items in the list fails.
The successfully refiled items and the first failed item have to be excluded from the list and the
process has to be restarted. This needs the attention of an administrator and time. A short list
reduces the risk but is more time consuming to create.
Develop a load balancing strategy
The load balance between the clients used for the refile order has to be equally divided and
controlled.
Create batch scripts for every client and use it to start the ugmanager_refile utility. Using this
method makes it possible to modify the batch scripts during the process and change the order.
This can be controlled using the input lists and if a refile job in the first 5 categories fails, it is
necessary to handle these errors immediately. When the problem is fixed, the scripts can be
modified and restarted.
Handling the errors
Measure the failure rate
There are two log files for review:
Failed_refiles.log and ugmanager_refile.log (or, as given in the command line)
If a part is marked as failed in the ugmanager_refile.log it is noted with the error message in the
failed_refiles.log.
To get the rate of success take the values for “Successfully processed” and “Failed to
process” in the ugmanager_refile.log:
** Refiling Complete **
Successfully processed: 117 (20 non-masters)
Failed to process: 4 (1 non-masters)
Unable to process: 0 (0 non-masters)
Now calculate:
”failed” * 100 / (“Successful” + “failed”) = rate
In the example:
4 *100 / (117 + 4) = 3.3 % => It is too high!
Define actions to fix the problems
To reduce the rate, analyze the failed_refiles.log, find the reasons and fix them .
Identify the problem and find a fix using the UGSolution database
(http://uganswer.ugs.com/qcksrch.stm) or contact the local GTAC organization.
E.g. select a client with enough memory to load the assembly.
Check the failed parts in the old version. Is it possible to load it? If possible, repair it in the old
version. E.g. Errors because of conflicting mating conditions during a structure update.
Refile the failed parts
Now create new input lists containing the fixed failed parts and start the refile again. If the job is
not a part of a category with priority it can be done some time during the next working days.
Thomas Koppe