on 06-25-2009 4:29 PM
Hi
We are having an issue while restoring data from the backup. (SAP ECC 6.0 - Unicode / Oracle 10g / HP-UX 11.23)
when try to restore oracle datafiles from the backup of our production, all the files which are restored are 8192 Bytes less in size compared to our production backup, so when we startup oracle we are facing issues.
We have compared the filesystem properties itu2019s the same as production and also its set to largefiles=yes.
We tried restored the previous day's backups but all files restored are one block (8192 Bytes) less in size.
Say for example if the system datafile original size is 2147491840 Bytes the size after restoration in the target system is 2147483648 Bytes, which is 8192 Bytes less.
Our Target system is running in IVM (virtual host).
When we restore the same backup to a physical standalone system, the data is restored correctly.
Do we need to make any special changes at unix / filesytem level to make the restore files correct with exact size?
Given below is the fstyp of our IVM sytem filesystem
fstyp -v /dev/vg01/lvol2
vxfs
version: 5
f_bsize: 8192
f_frsize: 1024
f_blocks: 125829120
f_bfree: 36536857
f_bavail: 34253304
f_files: 9134500
f_ffree: 9134212
f_favail: 9134212
f_fsid: 1073807362
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 16
f_fsindex: 9
f_size: 125829120
The init<SID>.sap file contents are
backup_mode = all
restore_mode = all
backup_type = offline_force
backup_dev_type = tape
backup_root_dir = /oracle/TU3/sapbackup
stage_root_dir = /oracle/TU3/sapbackup
compress = hardware
compress_cmd = "compress -c $ > $"
uncompress_cmd = "uncompress -c $ > $"
compress_dir = /oracle/TU3/sapreorg
archive_function = save
archive_copy_dir = /oracle/TU3/sapbackup
archive_stage_dir = /oracle/TU3/sapbackup
tape_copy_cmd = dd
disk_copy_cmd = copy
stage_copy_cmd = rcp
pipe_copy_cmd = rsh
dd_flags = "obs=64k bs=128k"
dd_in_flags = "ibs=64k bs=128k"
saveset_members = 1
copy_out_cmd = "dd ibs=8k obs=64k of=$"
copy_in_cmd = "dd ibs=64k obs=8k if=$"
rewind = "mt -t $ rew"
rewind_offline = "mt -t $ offl"
tape_pos_cmd = "mt -t $ fsf $"
tape_size = 180000M
tape_size_arch = 180000M
exec_parallel = 0
tape_address = /dev/rmt/1mn
tape_address_arch = /dev/rmt/1mn
tape_address_rew = /dev/rmt/1mb
tape_address_rew_arch = /dev/rmt/1m
expir_period = 2
tape_use_count = 100
volume_archive=(TU3A01, TU3A02, TU3A03, TU3A04, TU3A05,
TU3A06, TU3A07, TU3A08, TU3A09, TU3A10,
TU3A11, TU3A12, TU3A13, TU3A14, TU3A15,
TU3A16, TU3A17, TU3A18, TU3A19, TU3A20,
TU3A21, TU3A22, TU3A23, TU3A24, TU3A25,
TU3A26, TU3A27, TU3A28, TU3A29, TU3A30)
volume_backup=(TU3B01, TU3B02, TU3B03, TU3B04, TU3B05,
TU3B06, TU3B07, TU3B08, TU3B09, TU3B10,
TU3B11, TU3B12, TU3B13, TU3B14, TU3B15,
TU3B16, TU3B17, TU3B18, TU3B19, TU3B20,
TU3B21, TU3B22, TU3B23, TU3B24, TU3B25,
TU3B26, TU3B27, TU3B28, TU3B29, TU3B30)
Can anyone help on this regard
Thanks & Regards
Senthil
> Our Target system is running in IVM (virtual host).
That means you use HP Integrity Virtual Machine?
Note 1351051 - Support of Oracle for HP-UX Itanium Integrity VM
> When we restore the same backup to a physical standalone system, the data is restored correctly.
>
> Do we need to make any special changes at unix / filesytem level to make the restore files correct with exact size?
This is really a strange (and serious) problem. I could imagine, that the "virtual" disks created need a certain alignment which is, for whatever reason, not accomplished and so hence "cutting" the last block.
If you run the version mentioned in the note I would create an OSS call @ SAP for Oracle (BC-DB-ORA) and also involve HP into the process.
Markus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
HI
We have faced this problem recently. We highlighted this issue to HP,Bangalore and SAP. Till no reply.
After LTO 4 tape drive installed , we got this error. Earlier we have no problem with LTO 3. Server Details
HP-IVM- Production test server - ECC 6.0 - Oracle 10.2.0.4
recover database using backup controlfile until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 1: '/oracle/SFP/sapdata1/system_1/system.data1'
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/oracle/SFP/sapdata1/system_1/system.data1'
ORA-01200: actual file size of 44799 is smaller than correct size of 44800
blocks
Regards
Ravi.S
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you Markus & Michael.
We reported the issue to SAP and HP. The issue is currently in their R&D division
We tried different permutations and combinations, finally when we take the backup from the single OS using the parameter
dd_flags = "obs=8k bs=8k"
dd_in_flags = "ibs=8k bs=8k"
in the init<SID>.sap file, then it can be restored in the IVM server with the same above parameter.
Even less than 8K works, but above 8K doesn;t work.
The disadvantage is it consumes lot more time to take the backup and restore.
Regards
Senthil
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As mentioned above contact support.
Can you please post the output from both systems:
du -k <file>
ls -l <file>
cksum <file>
so when we startup oracle we are facing issues
What errors do you get?
What happens if you just copy a datafile to a virtual server? Are you using shared I/O(virtualized Luns) or attached I/O? On OS level please verify if you have the same filesystem (vxfs, jfs) versions and the same patch level.
Regards, Michael
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.