Upgrading a Perforce Server

How do I upgrade to a new version of the Perforce Server?

To run a newer version of the Perforce Server, your Perforce license must be current. You will not be able to upgrade to a Perforce Server version that is dated beyond your license expiry. This is not a problem if you are running an unlicensed installation, which is limited to two users and two (2004.2 and earlier) or five (2005.1 and later) client workspaces. An unlicensed installation is sometimes used for evaluating Perforce.

Please be sure to read the P4D Release Notes before proceeding with your upgrade to be aware of the latest changes to the current Perforce Server version.

In general, you cannot downgrade a Perforce Server. It is therefore imperative that you create a checkpoint prior to upgrading to a new version.

In general, you can upgrade from any previous version of the Perforce Server. For example, you can upgrade directly from a 2007.2 version to 2009.2. There is no need to perform any incremental upgrade; the built-in upgrade process automatically performs the incremental Perforce database updates and reports them.

Assuming you have a good license (or are running an unlicensed two user/two or five client workspace installation), and you are upgrading from a recent release, Perforce Server upgrading can be as simple as performing the following steps:

Stop the current p4d.Make a checkpoint of the database by issuing the following command, where "root" is the directory in which your db.* files are located:p4d -r root -jcBack up the versioned files.Download the new p4d executable. Note: On Windows, download the perforce.exe or perforce64.exe installer.
Install the new p4d in the desired location. Note: On Windows, run the perforce.exe or perforce64.exe installer.Run the following command:p4d -r root -xuRestart p4d with your usual parameters.

There is an optional task to consider after completing the upgrade. It would be an opportune time to make a checkpoint of your newly upgraded database, in case there is a subsequent need to recover the db.* files. To make a new checkpoint, repeat steps 1 and 2 from the preceding list.

See Supporting Perforce: Backup and Recovery in the Perforce System Administrator's Guide for information on making a checkpoint of the database and backing up the versioned files.

If you are upgrading the Perforce server from a release prior to 2001.1, there may be additional considerations. To ensure a successful upgrade from releases prior to 2001.1, please send an email to support@perforce.com.

For upgrades to release 2005.1 and later, p4 verify -u must be run at least once following the upgrade to generate file length data for any files in your depot before the upgrade. For more information, see: Important Notes for 2005.1 and later.

Older Perforce client programs (p4, P4Win, and P4SCC) work with newer server versions with no trouble. Some features in a new server release require a client upgrade as well; users with older client programs cannot use the new server features.

Perforce's remote depot support requires all your Perforce Servers to be at or above Release 98.2. 2005.1 and later servers can be used as remote depots from only 99.2 and later servers.

Significant metadata database schema upgrades are performed by the p4d -xu command. The p4d -xu command is generally required when upgrading a server with 1000 or more changelists. If a server has fewer than 1000 changelists, it is automatically upgraded when the new server is started. Attempting to start a new server using a metadata database containing 1000 or more changelists, and for which significant schema upgrades are needed, results in the following server error:

Database is at old upgrade level x. Use 'p4d -xu' to upgrade to level y

where x and y are server internal upgrade levels.

After writing the error, the server terminates. On Windows, error messages are written to the server log but are not displayed.

The p4d -xu command is not required for all server upgrades. For example, p4d -xu is not required when upgrading a 2005.2 server to 2006.1, regardless of the number of changelists. But this does not imply that a 2006.1 server can be downgraded to 2005.2 by simply starting a 2005.2 server using a metadata database previously used by a 2006.1 server. New servers make additional schema modifications in the metadata database as the new server executes.

For most upgrades, additional space is required for both the db.* files and the journal. The maximum additional space required for each of these during the p4d -xu is listed in the following tables. For most upgrades, the actual additional space used is less than what is listed in the tables, since what is listed is based upon a worst-case scenario.

Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journalPlease see 2008.1 -xu for upgrade requirements from earlier versions
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal
Upgrading from
releaseMaximum additional space
required for db.* filesMaximum additional space
required for journal

If you are upgrading the Perforce server from a release prior to 2002.1, and you use jobs, you must run p4 jobs -R to reindex the jobs. The maximum additional space required for the db.* files during the p4 jobs -R is equal to the size of db.ixtext. The maximum additional space required for the journal during the p4 jobs -R is the sum of three times the size of db.ixtext, twice the size of db.boddate, twice the size of db.bodtext, and twice the size of db.ixdate, or (3x size of db.ixtext) + (2x size of db.boddate) + (2x size of db.bodtext) + (2x size of db.ixdate).

To minimize the additional space required for the journal, disable journaling during the upgrade. Be sure to re-enable journaling and make a checkpoint immediately following the successful upgrade. For information on enabling and disabling journaling, see the "Journal files" section of Supporting Perforce: Backup and Recovery in the Perforce System Administrator's Guide.

View the original article here