The solution for migrating db2 v9.5 to v10.5 and failing to create a database with duplicate names can be recovered using backup in the same version of the system. This article assumes that different versions of the system use the db2move command. 1. db2move db db_name export Note: first create a directory to put the file. Because there are many files, if the file is export, it will be generated in the current directory. Mkdir/home/backup/mydata: enter this directory for command execution. 2. Create an empty database with the same name before running the db2move db db_name import command. Copy the folder to the mydata directory and run the command. Note: 1. Using this method requires that the database table be simple, without triggers, stored procedures, and views, and there cannot be auto-increment of identity. 2. All commands must be executed under the root user. At least mine is like this. If not, [java] Application code page not determined, using ANSI codepage 1208 will be prompted: when LZ creates a database with the same name as the database in the local catalog, the create operation fails. Therefore, the node is directly uncatalog and the db cannot be dropped. this method is wrong, so you should immediately return to the original state (the method for returning to the original state is to catalog node again) with the duplicate Name node and db, first uncatalog db db_name, in this way, the db2 list db directory will no longer exist. At this time, the db2 list node directory has nodes, so that the node will be uncatalog. the order must not be messy. When a database is created, does the prompt still exist? Delete the db_name folder in node0000. If the prompt "db_name is exits on local or..." is displayed, re-enter the command interface and create again.