Upgrading Pre-2001.1 Servers

Info & Tags

Article #:
529
Created:
07/18/06
Modified:
05/26/08
Tags:
p4d

Links

  1. Backup and Recovery
    Perforce System Administrator's Guide
  2. Upgrading a Perforce Server
    Tech Note

SUMMARY

 

Upgrading pre-2002.1 servers

When upgrading to 2002.1 or later, additional disk space is required. The maximum disk space requirements are:

P4ROOT filesystem:
  • The size of "db.change", plus
  • The size of "db.ixtext".
Journal filesystem:
  • The size of "db.change", plus
  • Three times the size of "db.ixtext", plus
  • Twice the size of "db.boddate", "db.bodtext", and "db.ixdate".
These additional disk space requirements are related to the following changes:
  • Pending changelists are now in a "db.changex" table (change 29365).
  • Jobs searching supports matching punctuation (change 27808).
The pending changelists are copied from "db.change" to "db.changex" as part of the server command: 
p4d -xu
Copying the pending changelists requires additional disk space. Assuming a worst case of all changelists being pending changelists, the amount of available disk space required in the filesystem where P4ROOT is located is approximately equal to the size of the "db.change" file. If journaling is enabled, the amount of additional disk space required in the file system where the journal is located is approximately equal to the size of the "db.change" file, in the worst case.

To implement job search punctuation matching,  jobs must be re-indexed using: 
p4 jobs -R.
Re-indexing results in an increase in the size of "db.ixtext", due to the new whitespace-delimited words added to the index. The amount of the increase in size depends on the amount of punctuation in your jobs. Assuming a worst case of every pair of words in jobs separated by punctuation, the amount of available disk space required in the file system where P4ROOT is located is approximately equal to the size of the "db.ixtext" file.

If journaling is enabled during "p4 jobs -R", all records rewritten for the "db.boddate", "db.bodtext", "db.ixdate", and "db.ixtext" files are journaled. Both deletes and adds for every entry in these files are journaled for each job that is re-indexed. Therefore, if journaling is enabled, the amount of additional disk space required in the file system where the journal is located is approximately equal to three times the size of the "db.ixtext" file plus twice the size of the "db.boddate", "db.bodtext", and "db.ixdate" files", in the worst case.

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

 

Upgrading pre-2001.1 servers

In the 2001.1 release, significant changes were made to the database schema. The changes included:
  • "db.have" split into "db.have" and "db.label" (change 21633)
  • "db.integ" split into "db.integed" and "db.resolve" (change 21574)

In pre-2001.1 servers, "db.have" and "db.integ" can require significant disk space. To convert these files to the 2001.1 schema, the upgrade process requires available disk space up to the size of the pre-2001.1 "db.have" and "db.integ" files if journaling is not enabled, or up to three times the size of the pre-2001.1 "db.have" and "db.integ" files if journaling is enabled. In some cases, the available disk space requirements may exceed these approximations.

To understand these space requirements of the 2001.1 upgrade process, consider an example 2000.2 database: 

% setenv P4CLIENT upgrade-client
% setenv P4JOURNAL journal
% setenv P4PORT zin:1666
% /releases/2000.2/p4d -r /p4roots/upgrade &
[1] 13448
Perforce Server starting...
Create a client specification: 
% p4 client
...
Client upgrade-client saved.
Add a file: 
% mkdir main
% cd main
% touch foo
% p4 add foo
//depot/main/foo#1 - opened for add
/p4clients/upgrade/main/foo - empty, assuming text.
% p4 submit
...
Change 1 created with 1 open file(s).
Submitting change 1.
Locking 1 files ...
add //depot/main/foo#1
Change 1 submitted.
Branch the file: 
% p4 integ //depot/main/foo //depot/branch/foo
//depot/branch/foo#1 - branch/sync from //depot/main/foo#1
% p4 submit
...
Change 2 created with 1 open file(s).
Submitting change 2.
Locking 1 files ...
branch //depot/branch/foo#1
Change 2 submitted.
Label both files: 
% p4 label bar
...
Label bar saved.
% p4 labelsync -l bar //depot/...
//depot/branch/foo#1 - added
//depot/main/foo#1 - added
Modify the branched file: 
% cd ../branch
% p4 edit foo
//depot/branch/foo#1 - opened for edit
% echo 123 >foo
% p4 submit
...
Change 3 created with 1 open file(s).
Submitting change 3.
Locking 1 files ...
edit //depot/branch/foo#2
Change 3 submitted.
Integrate back into main and schedule a resolve: 
% p4 integ //depot/branch/foo //depot/main/foo
//depot/main/foo#1 - integrate from //depot/branch/foo#2
% p4 submit
...
Change 4 created with 1 open file(s).
Submitting change 4.
//upgrade-client/main/foo - must resolve //depot/branch/foo#2
Merges still pending -- use 'resolve' to merge files.
Submit failed -- fix problems above then use 'p4 submit -c 4'.
Now that our example 2000.2 database is complete, make a checkpoint of the database and back up the versioned files: 
% p4 admin stop
Perforce Server stopped...
[1]  + Done                          /releases/2000.2/p4d -r /p4roots/upgrade
% /releases/2000.2/p4d -jc -r /p4roots/upgrade
Checkpointing to checkpoint.1...
Saving journal to journal.0...
Truncating journal...
% tar cf /backups/versionedfiles.tar -P /p4roots/upgrade/depot
For understanding the space requirements of the 2001.1 upgrade that is about to occur on our example database, note that the pre-2001.1 database contains four rows in the "db.have" table and three rows in the "db.integ" table. You can see this by browsing the checkpoint: 
% grep db.have /p4roots/upgrade/checkpoint.1

@pv@ 1 @db.have@ @//bar/branch/foo@ @//depot/branch/foo@ 1 0 
@pv@ 1 @db.have@ @//bar/main/foo@ @//depot/main/foo@ 1 0 
@pv@ 1 @db.have@ @//upgrade-client/branch/foo@ @//depot/branch/foo@ 2 0 
@pv@ 1 @db.have@ @//upgrade-client/main/foo@ @//depot/main/foo@ 1 0 

% grep db.integ /p4roots/upgrade/checkpoint.1

@pv@ 0 @db.integ@ @//depot/branch/foo@ @//depot/main/foo@ 0 1 1 2 1 2 2 
@pv@ 0 @db.integ@ @//depot/main/foo@ @//depot/branch/foo@ 0 1 1 3 1 2 2 
@pv@ 0 @db.integ@ @//upgrade-client/main/foo@ @//depot/branch/foo@ 1 2 1 6 ...
Upgrade the database: 
% /releases/2001.1/p4d -xu -r /p4roots/upgrade
2001.1: splitting db.integ into db.integed and db.resolve.
2001.1: splitting db.have into db.have and db.label.
...upgrades done
Restart the server and make a checkpoint that you can browse to see the results of the upgrade. You can also browse the journal from the upgrade: 
% /releases/2001.1/p4d -r /p4roots/upgrade &
[1] 13631
Perforce Server starting...
% p4 admin checkpoint
Checkpointing to checkpoint.2...
Saving journal to journal.1...
Truncating journal...
Note that db.have now contains two rows, db.label contains two rows, db.integ now contains zero rows, db.integed contains two rows, and db.resolve contains one row: 
% grep db.have /p4roots/upgrade/checkpoint.2

@pv@ 1 @db.have@ @//upgrade-client/branch/foo@ @//depot/branch/foo@ 2 0 
@pv@ 1 @db.have@ @//upgrade-client/main/foo@ @//depot/main/foo@ 1 0 

% grep db.label /p4roots/upgrade/checkpoint.2

@pv@ 0 @db.label@ @bar@ @//depot/branch/foo@ 1 
@pv@ 0 @db.label@ @bar@ @//depot/main/foo@ 1 

% grep db.integ@ /p4roots/upgrade/checkpoint.2

% grep db.integed /p4roots/upgrade/checkpoint.2

@pv@ 0 @db.integed@ @//depot/branch/foo@ @//depot/main/foo@ 0 1 0 1 2 2 
@pv@ 0 @db.integed@ @//depot/main/foo@ @//depot/branch/foo@ 0 1 0 1 3 2 

% grep db.resolve /p4roots/upgrade/checkpoint.2

@pv@ 0 @db.resolve@ @//upgrade-client/main/foo@ @//depot/branch/foo@ 1 2 0 0 ...
The upgrade added the two labeled file records to the newly created "db.label" table and deleted the two labeled file records from the "db.have" table. The upgrade added the two integration records to the newly created "db.integed" table and deleted the two integration records from the "db.integ" table. The upgrade added the scheduled resolve record to the newly created "db.resolve" table and deleted the scheduled resolve record from the "db.integ" table. You can see this activity browsing the journal from the upgrade (deletions appear in the journal as dv records; additions appear in the journal as pv records): 
% cat /p4roots/upgrade/journal.1

...
@pv@ 0 @db.integed@ @//depot/branch/foo@ @//depot/main/foo@ 0 1 0 1 2 2 
@dv@ 0 @db.integ@ @//depot/branch/foo@ @//depot/main/foo@ 0 1 1 2 1 2 2 
@pv@ 0 @db.integed@ @//depot/main/foo@ @//depot/branch/foo@ 0 1 0 1 3 2 
@dv@ 0 @db.integ@ @//depot/main/foo@ @//depot/branch/foo@ 0 1 1 3 1 2 2 
@pv@ 0 @db.resolve@ @//upgrade-client/main/foo@ @//depot/branch/foo@ 1 2 0 0 ...
@dv@ 0 @db.integ@ @//upgrade-client/main/foo@ @//depot/branch/foo@ 1 2 1 6 ...
...
@pv@ 0 @db.label@ @bar@ @//depot/branch/foo@ 1 
@dv@ 1 @db.have@ @//bar/branch/foo@ @//depot/branch/foo@ 1 0 
@pv@ 0 @db.label@ @bar@ @//depot/main/foo@ 1 
@dv@ 1 @db.have@ @//bar/main/foo@ @//depot/main/foo@ 1 0 
...
For each labeled file record in the "db.have" table, one record is inserted into the "db.label" table, and the labeled file record is deleted from the "db.have" table. If journaling is enabled, for each labeled file record in the "db.have" table, one record is added to the journal for the insert into the "db.label" table, and another record is added to the journal for the delete from the "db.have" table. Therefore, the amount of space required for the conversion of the "db.have" table is approximately equal to the space required for all the labeled file records in the "db.have" table if journaling is not enabled, or approximately three times the space required for all the labeled file records in the "db.have" table if journaling is enabled. These space requirements are approximate due to differing record formats between the "db.have" and "db.label" tables, and the varying space requirements of the text journal records.

For each record in the "db.integ" table, one record is inserted into the "db.integed" or "db.resolve" table, and the record is deleted from the "db.integ" table. If journaling is enabled, for each record in the "db.integ" table, one record is added to the journal for the insert into the "db.integed" or "db.resolve" table, and another record is added to the journal for the delete from the "db.integ" table. Therefore, the amount of space required for the conversion of the "db.integ" table is approximately equal to the space required for all the records in the "db.integ" table if journaling is not enabled, or approximately three times the space required for all the records in the "db.integ" table if journaling is enabled. These space requirements are approximate due to differing record formats between the "db.integ", "db.integed", and "db.resolve" tables, and the varying space requirements of the text journal records.

The worst-case upgrade is when the "db.have" table is mostly composed of labeled file records and journaling is enabled at the time of the upgrade. Under this scenario, the amount of available disk space required for the upgrade can be calculated as follows:

  disk space used by existing "db.have" +
  (2 * disk space used by existing db.have) +
  disk space used by existing "db.integ" +
  (2 * disk space used by existing db.integ)

= (3 * disk space used by existing db.have) +
  (3 * disk space used by existing db.integ)

= 3 * disk space used by existing "db.have" and db.integ
To minimize disk space required for the upgrade, disable journaling during the upgrade. If journaling is disabled during the upgrade, the amount of available disk space required for the worst-case upgrade is reduced to approximately the amount of disk space used by the existing "db.have" and "db.integ" tables. If journaling is disabled, be sure to re-enable journaling and make a checkpoint immediately following a successful upgrade. For information on enabling and disabling journaling, see Backup and Recovery in the Perforce System Administrator's Guide.

After the database has been successfully upgraded, disk space can be reclaimed by deleting the "db.integ" file. However, the deleted space within the "db.have" table might not be immediately reclaimed.

Warning: The 2001.1 upgrade cannot be downgraded -- After a database has been upgraded to 2001.1 or later, it cannot easily be returned to the state that existed prior to the upgrade. To have the option of reverting to a pre-2001.1 server, make a checkpoint of the database and a backup of the versioned files prior to performing the 2001.1 database upgrade. If you upgrade a database by mistake, contact Perforce Technical Support at support@perforce.com.

If a pre-2001.1 p4d is started using a database that has been upgraded to 2001.1, the server appears to start correctly. However, any attempted operation results in an error from the server: 

% /releases/2000.2/p4d -r /p4roots/upgrade &
[1] 14439
Perforce Server starting...
% p4 info
Perforce server error:
        Date 2001/05/03 12:02:04:
        Database open error on db.depot!
        dbopen: db.depot: Invalid argument
Date 2001/05/03 12:02:04:
Database open error on db.depot!
dbopen: db.depot: Invalid argument
Perforce client error:
        TCP send failed.
        write: socket: Broken pipe
% p4 admin stop
Perforce server error:
        Date 2001/05/03 12:02:38:
        Database open error on db.depot!
        dbopen: db.depot: Invalid argument
Perforce client error:
        TCP send failed.
        write: socket: Broken pipe
% kill 14439
Perforce server error:
        Database open error on db.counters!
        dbopen: db.counters: Invalid argument
[1]    Exit 255                      /releases/2000.2/p4d -r /p4roots/upgrade
If a pre-2001.1 p4d is started using a database that has been upgraded to 2001.1, the database should not be damaged. After terminating the pre-2001.1 p4d, restart the server with the 2001.1 p4d.
Restarting the upgrade
In most cases, a failed upgrade can be restarted after the condition causing the failure has been corrected. Restarting the upgrade does not result in a duplicate record if the upgrade fails just after a record has been inserted into the "db.label", "db.integed", or "db.resolve" table, and before the record has been deleted from the "db.have" or "db.integ" table. When the upgrade is restarted, the record that was not yet deleted from the "db.have" or "db.integ" table is again inserted into the "db.label", "db.integed", or "db.resolve" table, but it will be inserted at the same location where the previous insertion of the same record occurred.
Loading pre-2001.1 checkpoints with 2001.1 p4d
You can load a checkpoint made with a pre-2001.1 p4d using a 2001.1 p4d. However, doing so does not enable you to upgrade a database without the additional space requirements described above. The 2001.1 p4d loads the pre-2001.1 checkpoint into the same database structure that existed when the pre-2001.1 checkpoint was created; it does not upgrade the database as the 2001.1 p4d loads the pre-2001.1 checkpoint. After the pre-2001.1 checkpoint has been loaded, the database is then upgraded by the 2001.1 p4d when it is started with the -xu argument, or automatically upgraded if the database has less than 1000 changes when the 2001.1 p4d is started.

To better understand how a pre-2001.1 checkpoint is loaded and upgraded by the 2001.1 p4d, you can load our pre-2001.1 checkpoint that was created above: 

% pwd
/p4roots/upgrade
% ls -l
total 4
-r--r--r--    1 user     group        2168 May  2 22:31 checkpoint.1
% /releases/2001.1/p4d -r /p4roots/upgrade -jr /p4roots/upgrade/checkpoint.1

Recovering from /p4roots/upgrade/checkpoint.1...
% tar xf /backups/versionedfiles.tar -Pp
% ls -l
...
-rw-r--r--    1 user     group        8192 May  3 06:39 db.have
-rw-r--r--    1 user     group        8192 May  3 06:39 db.integ
-rw-r--r--    1 user     group        8192 May  3 06:39 db.integed
...
-rw-r--r--    1 user     group        8192 May  3 06:39 db.label
...
-rw-r--r--    1 user     group        8192 May  3 06:39 db.resolve
...
The 2001.1 p4d created the new 2001.1 tables "db.integed", "db.label", and "db.resolve". To determine whether the database has been upgraded, make another checkpoint that you can browse: 
% /releases/2001.1/p4d -r /p4roots/upgrade -jc
Checkpointing to checkpoint.2...
Saving journal to journal.1...
Truncating journal...

% grep db.have /p4roots/upgrade/checkpoint.2

@pv@ 1 @db.have@ @//bar/branch/foo@ @//depot/branch/foo@ 1 0 
@pv@ 1 @db.have@ @//bar/main/foo@ @//depot/main/foo@ 1 0 
@pv@ 1 @db.have@ @//upgrade-client/branch/foo@ @//depot/branch/foo@ 2 0 
@pv@ 1 @db.have@ @//upgrade-client/main/foo@ @//depot/main/foo@ 1 0 

% grep db.label /p4roots/upgrade/checkpoint.2

% grep db.integ@ /p4roots/upgrade/checkpoint.2

@pv@ 0 @db.integ@ @//depot/branch/foo@ @//depot/main/foo@ 0 1 1 2 1 2 2 
@pv@ 0 @db.integ@ @//depot/main/foo@ @//depot/branch/foo@ 0 1 1 3 1 2 2 
@pv@ 0 @db.integ@ @//upgrade-client/main/foo@ @//depot/branch/foo@ 1 2 1 6 ...

% grep db.integed /p4roots/upgrade/checkpoint.2

% grep db.resolve /p4roots/upgrade/checkpoint.2
The database has not been upgraded. The labeled file records have not been moved from the "db.have" table into the "db.label" table, and the records have not been moved from the "db.integ" table into the "db.integed" or "db.resolve" table.

Starting the 2001.1 p4d upgrades the database automatically, because there are less than 1000 changes in our example database: 

% /releases/2001.1/p4d -r /p4roots/upgrade &
[1] 14103
Perforce Server starting...
Make a checkpoint that you can browse to verify that the upgrade has occurred. You can also browse the journal: 
% p4 admin checkpoint
Checkpointing to checkpoint.3...
Saving journal to journal.2...
Truncating journal...
From this latest checkpoint and journal, you can verify that the database has been upgraded: 
% grep db.have /p4roots/upgrade/checkpoint.3

@pv@ 1 @db.have@ @//upgrade-client/branch/foo@ @//depot/branch/foo@ 2 0 
@pv@ 1 @db.have@ @//upgrade-client/main/foo@ @//depot/main/foo@ 1 0 

% grep db.label /p4roots/upgrade/checkpoint.3

@pv@ 0 @db.label@ @bar@ @//depot/branch/foo@ 1 
@pv@ 0 @db.label@ @bar@ @//depot/main/foo@ 1 

% grep db.integ@ /p4roots/upgrade/checkpoint.3

% grep db.integed /p4roots/upgrade/checkpoint.3

@pv@ 0 @db.integed@ @//depot/branch/foo@ @//depot/main/foo@ 0 1 0 1 2 2 
@pv@ 0 @db.integed@ @//depot/main/foo@ @//depot/branch/foo@ 0 1 0 1 3 2 

% grep db.resolve /p4roots/upgrade/checkpoint.3

@pv@ 0 @db.resolve@ @//upgrade-client/main/foo@ @//depot/branch/foo@ 1 2 0 0 ...

% cat /p4roots/upgrade/journal.2
...
@pv@ 0 @db.integed@ @//depot/branch/foo@ @//depot/main/foo@ 0 1 0 1 2 2 
@dv@ 0 @db.integ@ @//depot/branch/foo@ @//depot/main/foo@ 0 1 1 2 1 2 2 
@pv@ 0 @db.integed@ @//depot/main/foo@ @//depot/branch/foo@ 0 1 0 1 3 2 
@dv@ 0 @db.integ@ @//depot/main/foo@ @//depot/branch/foo@ 0 1 1 3 1 2 2 
@pv@ 0 @db.resolve@ @//upgrade-client/main/foo@ @//depot/branch/foo@ 1 2 0 0 ...
@dv@ 0 @db.integ@ @//upgrade-client/main/foo@ @//depot/branch/foo@ 1 2 1 6 ...
...
@pv@ 0 @db.label@ @bar@ @//depot/branch/foo@ 1 
@dv@ 1 @db.have@ @//bar/branch/foo@ @//depot/branch/foo@ 1 0 
@pv@ 0 @db.label@ @bar@ @//depot/main/foo@ 1 
@dv@ 1 @db.have@ @//bar/main/foo@ @//depot/main/foo@ 1 0 
...
Loading pre-2001.1 journals with 2001.1 p4d

Loading pre-2001.1 journals with the 2001.1 p4d functions in much the same way as loading pre-2001.1 checkpoints with the 2001.1 p4d. However, it is important that the pre-2001.1 journals are loaded before the 2001.1 database upgrade occurs. Loading a pre-2001.1 journal after upgrading the database can result in missing data. In reality, the data is not missing, but rather it is loaded to its pre-2001.1 table and was not loaded when the database upgrade would have moved it to the table where it resides for 2001.1.

To illustrate this potential problem, load the pre-2001.1 checkpoint that was created above: 

% pwd
/p4roots/upgrade
% ls -l
total 4
-r--r--r--    1 user     group        2168 May  2 22:31 checkpoint.1
% /releases/2000.2/p4d -r /p4roots/upgrade -jr /p4roots/upgrade/checkpoint.1

Recovering from /p4roots/upgrade/checkpoint.1...
% tar xf /backups/versionedfiles.tar -Pp
Continuing to work in the example 2000.2 database, add a file: 
% /releases/2000.2/p4d -r /p4roots/upgrade &
[1] 18102
Perforce Server starting...
% cd /p4clients/upgrade/main
% touch baz
% p4 add baz
//depot/main/baz#1 - opened for add
/p4clients/upgrade/main/baz - empty, assuming text.
% p4 submit
...
Change 5 created with 1 open file(s).
Submitting change 5.
Locking 1 files ...
add //depot/main/baz#1
Change 5 submitted.
Add the added file to a label: 
% p4 labelsync -l bar baz
//depot/main/baz#1 - added
% p4 files @bar
//depot/branch/foo#1 - branch change 2 (text)
//depot/main/baz#1 - add change 5 (text)
//depot/main/foo#1 - add change 1 (text)
Save the pre-2001.1 journal containing the file addition and the labeled file record for the added file: 
% p4 admin stop
Perforce Server stopped...
[1]    Done                          /releases/2000.2/p4d -r /p4roots/upgrade
% cd /p4roots/upgrade
% mv journal journal.2000.2
Switch to the 2001.1 p4d and restore the original example database: 
% rm db.*
% /releases/2001.1/p4d -r /p4roots/upgrade -jr /p4roots/upgrade/checkpoint.1

Recovering from /p4roots/upgrade/checkpoint.1...
Start the 2001.1 p4d, which automatically upgrades the example database, because it contains less than 1000 changes: 
% /releases/2001.1/p4d -r /p4roots/upgrade &
[1] 18125
Perforce Server starting...
% p4 counter upgrade
2
% p4 admin stop
Perforce Server stopped...
[1]  + Done                          /releases/2001.1/p4d -r /p4roots/upgrade
Load the pre-2001.1 journal into the upgraded database: 
% /releases/2001.1/p4d -r /p4roots/upgrade -jr /p4roots/upgrade/journal.2000.2

Recovering from /p4roots/upgrade/journal.2000.2...
Note that the added file is missing from the label: 
% /releases/2001.1/p4d -r /p4roots/upgrade &
[1] 18131
Perforce Server starting...
% p4 files @bar
//depot/branch/foo#1 - branch change 2 (text)
//depot/main/foo#1 - add change 1 (text)
Make a checkpoint that you can browse to find the missing labeled file record for the added file: 
% p4 admin checkpoint
Checkpointing to checkpoint.2...
Saving journal to journal.1...
Truncating journal...

% grep db.have /p4roots/upgrade/checkpoint.2

@pv@ 1 @db.have@ @//bar/main/baz@ @//depot/main/baz@ 1 1075069960 
@pv@ 1 @db.have@ @//upgrade-client/branch/foo@ @//depot/branch/foo@ 2 0 
@pv@ 1 @db.have@ @//upgrade-client/main/baz@ @//depot/main/baz@ 1 0 
@pv@ 1 @db.have@ @//upgrade-client/main/foo@ @//depot/main/foo@ 1 0 

% grep db.label /p4roots/upgrade/checkpoint.2

@pv@ 0 @db.label@ @bar@ @//depot/branch/foo@ 1 
@pv@ 0 @db.label@ @bar@ @//depot/main/foo@ 1
The labeled file record for the added file is in the "db.have" table, which is where it should be if this were a pre-2001.1 database. But of course, this database has been upgraded to 2001.1. The 2001.1 p4d loaded the labeled file record for the added file from the pre-2001.1 journal to the table specified in the journal record, which is the "db.have" table: 
% cat /p4roots/upgrade/journal.2000.2

...
@pv@ 1 @db.have@ @//bar/main/baz@ @//depot/main/baz@ 1 1075069960
If the 2001.1 database upgrade is run now, the labeled file record for the added file will be moved from the "db.have" table to where it should be for 2001.1, which is the "db.label" table. The upgrade can be forced to run again by resetting the upgrade counter: 
% p4 counter -f upgrade 0
Counter upgrade set.
% p4 counter upgrade
0
% p4 admin stop
Perforce Server stopped...
[1]    Done                          /releases/2001.1/p4d -r /p4roots/upgrade
Start the 2001.1 p4d, which automatically upgrades the database, because the upgrade counter indicates that the database needs to be upgraded and there are still less than 1000 changes: 
% /releases/2001.1/p4d -r /p4roots/upgrade &
[1] 18138
Perforce Server starting...
% p4 counter upgrade
2
The added file returns to the label: 
% p4 files @bar
//depot/branch/foo#1 - branch change 2 (text)
//depot/main/baz#1 - add change 5 (text)
//depot/main/foo#1 - add change 1 (text)
Making a checkpoint and browsing shows that indeed the labeled file record for the added file is now where it should be for 2001.1, which is the "db.label" table: 
% p4 admin checkpoint
Checkpointing to checkpoint.3...
Saving journal to journal.2...
Truncating journal...

% grep db.have /p4roots/upgrade/checkpoint.3

@pv@ 1 @db.have@ @//upgrade-client/branch/foo@ @//depot/branch/foo@ 2 0 
@pv@ 1 @db.have@ @//upgrade-client/main/baz@ @//depot/main/baz@ 1 0 
@pv@ 1 @db.have@ @//upgrade-client/main/foo@ @//depot/main/foo@ 1 0 

% grep db.label /p4roots/upgrade/checkpoint.3

@pv@ 0 @db.label@ @bar@ @//depot/branch/foo@ 1 
@pv@ 0 @db.label@ @bar@ @//depot/main/baz@ 1 
@pv@ 0 @db.label@ @bar@ @//depot/main/foo@ 1
 

Upgrading pre-98.1 servers

The preceding server upgrade procedure applies to an upgrade from Release 98.1 or later. To upgrade from earlier releases requires more work, because there was a change in low-level database support in 98.1 which made it impractical to provide the ability to read database files from pre-98.1 (97.3 and earlier) servers. The 98.1 and later servers can, however, read 97.3 format checkpoint files. Checkpoint files contain a plain text representation of all the data in the database files.

 

Upgrading 97.3 servers

To upgrade from Release 97.3, use the following procedure:
  1. Stop p4d
  2. Create a checkpoint file using: 
    p4d -r root -jc
  3. Make a complete backup of everything in your $P4ROOT (server root) directory
  4. Install the new p4d
  5. Remove the existing db.* files from your $P4ROOT directory
  6. Create new db.* files from the checkpoint using: 
    p4d -r root -jr checkpoint.n
  7. Restart p4d with your usual parameters

Upgrading pre-97.3 servers

Before you upgrade to the current release from a version earlier than Release 97.3, make a checkpoint using the 97.3 server. Use the following procedure:
  1. Stop p4d
  2. Download the 97.3 version of p4d and name it "p4d.973"
  3. Create a checkpoint using the 97.3 server 
    p4d.973 -r root -jc
  4. Make a complete backup of everything in $P4ROOT
  5. Download the new p4d and install it in the desired location
  6. Remove the existing db.* files from $P4ROOT
  7. Create new db.* files from the checkpoint using: 
    p4d -r root -jr checkpoint.n
  8. Restart p4d with your usual parameters

Upgrading on Windows

The Perforce installer for Windows automatically handles upgrading from pre-98.1 servers to pre-2001.1 servers. However, the Perforce installer cannot perform upgrades to 2001.1 or later servers. If you are upgrading to 2001.1 or later, see the "Upgrading pre-2001.1 servers" and "Upgrading pre-2002.1 servers" sections. For all servers, download the installer ("perforce.exe") and follow the installation dialogs.