What is wrong with this Redirected restore command - UDBv8.2 fp14 on Linux

[okonita]

Hi all,
This is a very urgent issue for my team. We are trying a Redirected restore the most current online DB2 UDBv8.2 backup copy from

prod disk to disk on another/test instance. Our environment is RedHat Linux. We have tried the following with failure: (1)

[db2prd1@aaanpudb1 /]$ db2 restore db AANPDM01 from "/stuff/ftp/bkp" taken at 20070525164103 to "/dmd/data" into AANNDM01

NEWLOGPATH "/dmt/log" redirect without rolling forward;

SQL1052N The database path "/dmd/data" does not exist.

Note: "/dmd/data" does not exist in the source DB2 Linux Production environment but categorically exist in the target DB2 Linux

Test environment. What I need is to restore restore from production to test.
[db2prd1@fsfnpudb1 /]$ <== prod_instance_DB
[db2inst1@target_server <== systest_instance_DB

(2) We then tried to sFTP the backup image copy to the test environment but not having much luck either. We got repeated failure

with this message:

sftp> put FSNPDM01.0.db2prd1.NODE0000.CATN0000.2007092504450 6.001
Uploading AANPDM01.0.db2prd1.NODE0000.CATN0000.2007092504450 6.001 to

/db2home/db2inst1/AANPDM01.0.db2prd1.NODE0000.CATN0000.2007092504450 6.001
AANPDM01.0.db2prd1.NODE0000.CATN0000.2007092504450 6.001 12% 3972MB 4.2MB/s 1:54:37 ETA. Couldn't write to

remote file
"/db2home/db2inst1/FSNPDM01.0.db2prd1.NODE0000.CATN0000.2007092504450 6.001": Failure ID mismatch (127219 != 3)


Could any of our redirected restore gurus please step in and shed some light on this technical matter! This will be highly

appreciated!!

Sincerely

okonita

[dewa81]

In your redirected restore command you should not specify TO CLAUSE unless the target database is not existing
If you are restoring to an existing database you should not mention that
Remove to "/dmd/data" from your restore command and try again, it will work

For the sftp problem either there are not enough permissions to write to the target directory or the space is exhausted