topic Re: frecover slow problem in Operating System - HP-UX

frecover slow problem

ng_7 — Sun, 16 Sep 2007 20:26:48 GMT

Dear experts,

We bought a 1/8 G2 ultrium autoloader recently. We are very satisfy with the backup speed, but the restoring is extreamly slow (more than 13 hours still not starting restore)

We don't have any backup software yet for this autoloader, thus, I use the below unix command to backup :

fbackup -f /dev/rmt/1m -i /prod/oraprod/ -i /app/applprod/ -n -I /tmp/index

and I wanted to restore only data from "/prod/oraprod/proddata",so the restore command we used was :

db1:/hld/orahld/hlddata# frecover -f /dev/rmt/1m -i /prod/oraprod/proddata -xFv

the restoring not started even after we wait for about 13 Hours.

Please advised on the above restoring command and proposed better restoring command.

thanks

regards
ng

Re: frecover slow problem

Bill Hassell — Sun, 16 Sep 2007 22:19:16 GMT

It is imperative to use a config file with fbackup with the contents like this:

blocksperrecord 4096
records 64
checkpointfreq 4096
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

Store it someplace like /etc/fbackup.cfg and use it like this:

fbackup -c /etc/fbackup.cfg -f /dev/rmt/1m -i /prod/oraprod/ -i /app/applprod/ -n -I /tmp/index

Now fbackup (and frecover) use shared memory to reach maximum performance. If you have a very small system yet are backing up thousands of files, you may be paging due to lack of RAM. Use vmstat when frecover is running to see if the po column is more than 1 digit (ie, 0-9)

Re: frecover slow problem

ng_7 — Mon, 17 Sep 2007 22:05:48 GMT

hi, thanks for your quick response, i '
ve tried to set the configuration file, and finished the fbackup by using the suggested fbackup command. When i trying to frestore
using the below command i got the error as shown below :

db1:/hld/orahld/hlddata# frecover -c /etc/fbackup.cfg -f /dev/rmt/1m -i /prod/oraprod/proddata -xFv
frecover(3242): illegal configuration file label (blocksperrecord) ignored
frecover(3242): illegal configuration file label (records) ignored
frecover(3242): illegal configuration file label (checkpointfreq) ignored
frecover(3242): illegal configuration file label (readerprocesses) ignored
frecover(3242): illegal configuration file label (maxretries) ignored
frecover(3242): illegal configuration file label (retrylimit) ignored
frecover(3242): illegal configuration file label (maxvoluses) ignored
frecover(3242): illegal configuration file label (filesperfsm) ignored

and the frestoring process is stuck at the last line again.

please help.

thanks

ng

Re: frecover slow problem

Bill Hassell — Tue, 18 Sep 2007 12:27:39 GMT

Don't use a config file with frecover. If you look at the man pages for fbackup and frecover, you'll see that frecover uses a totally different file and the frecover keywords only control recovery steps such as error handling. How much memory do you have in your machine?

Re: frecover slow problem

ng_7 — Tue, 18 Sep 2007 20:23:40 GMT

my memory is 4GB. When I tried on the below command, the problem persists

frecover -f /dev/rmt/1m -i /prod/oraprod/proddata -xFv

please help.

thanks

ng

Re: frecover slow problem

Bill Hassell — Wed, 19 Sep 2007 21:39:59 GMT

When frecover is running, please post the output of vmstat and swapinfo -tam.

Re: frecover slow problem

ng_7 — Wed, 19 Sep 2007 22:50:16 GMT

db1:/home/alson# swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 4096 0 4096 0% 0 - 1 /dev/vg00/lvol2
dev 4096 0 4096 0% 0 - 1 /dev/vg00/lvol9
reserve - 1625 -1625
memory 3101 1669 1432 54%
total 11293 3294 7999 29% - 0 -

db1:/home/alson# vmstat 10
procs memory page faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
3 0 0 157545 120445 13 5 0 0 0 0 0 2821 5912 894 7 2 91
3 0 0 133616 120389 0 0 0 0 0 0 0 1359 17681 267 46 5 50
2 0 0 132798 120389 0 0 0 0 0 0 0 1261 16800 195 19 7 74
3 0 0 131586 120389 0 0 0 0 0 0 0 1350 18514 249 31 8 61
3 0 0 131110 120389 0 0 0 0 0 0 0 1152 16971 196 44 7 49
3 0 0 131291 120389 5 0 0 0 0 0 0 1227 15364 296 44 6 50
3 2 0 132596 119401 47 19 0 0 0 0 0 2145 18023 619 15 11 74
1 2 0 128554 120356 28 5 0 0 0 0 0 1823 11575 768 12 3 85
2 3 0 145075 120356 2 0 0 0 0 0 0 1585 9704 667 29 3 68
2 1 0 140141 120356 0 0 0 0 0 0 0 1705 11446 745 31 4 65
2 1 0 120471 120356 0 0 0 0 0 0 0 1535 14325 491 35 7 58
2 0 0 127771 120356 0 0 0 0 0 0 0 1296 12354 266 19 5 76
3 0 0 137531 120324 0 0 0 0 0 0 0 1472 15842 265 34 6 60
3 0 0 129640 120324 0 0 0 0 0 0 0 1379 16708 247 46 6 48
3 0 0 144626 119263 43 19 0 0 0 0 0 1277 22117 220 43 12 46
2 0 0 129584 119263 5 0 0 0 0 0 0 1277 14208 202 21 7 73
2 0 0 120629 119263 28 12 0 0 0 0 0 1412 10641 282 29 3 68
2 1 0 137938 119263 3 0 0 0 0 0 0 1323 20852 234 26 10 64

Re: frecover slow problem

ng_7 — Thu, 20 Sep 2007 06:41:01 GMT

can tar able to do backup for size about 120GB ?

if can , may be we can try to use tar.

Re: frecover slow problem

Bill Hassell — Thu, 20 Sep 2007 07:26:51 GMT

tar can backup an unlimited amount of data but no file in any directory can be more than 2GB in size (or no more than 8GB for recent versions of tar).

Are you up to date on pateches (at least within one year)? What do these commands report:

model
uname -a
ipcs -bmop
kmtune -q maxdsiz
ulimit -a

Rather than try to backup a large set of files, try backing up /tmp, then read the index as a check:

frecover -I - -f /dev/rmt/1m

Also try reading the index from the oraprod backup using the same command.

Re: frecover slow problem

ng_7 — Fri, 21 Sep 2007 01:49:11 GMT

db1:/# model
9000/800/L3000-6x
db1:/# uname -a
HP-UX db1 B.11.11 U 9000/800 1120434655 unlimited-user license
db1:/# ipcs -bmop
IPC status from /dev/kmem as of Fri Sep 21 08:25:14 2007
T ID KEY MODE OWNER GROUP NATTCH SEGSZ CPID LPID
Shared Memory:
m 0 0x411c025d --rw-rw-rw- root root 0 348 620 620
m 1 0x4e0c0002 --rw-rw-rw- root root 1 61760 620 620
m 2 0x41200fdd --rw-rw-rw- root root 1 8192 620 632
m 3 0x301c6bd4 --rw-rw-rw- root root 3 1048576 1181 1197
m 102405 0xe5ebe34c --rw-r----- oraprod dba 91 742432768 13217 19224
db1:/# kmtune -q maxdsiz
Parameter Current Dyn Planned Module Version
===============================================================================
maxdsiz 0x4bc00000 - 0X4BC00000
db1:/# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 262144
stack(kbytes) 262144
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 2048
db1:/#

to backup and restore small file no problem.

FYI : try to use frecover -f /dev/rmt/1m -i /prod/oraprod/proddata -xv (without F), the problem persist as well.

thanks

Regards
ng

Re: frecover slow problem

Bill Hassell — Fri, 21 Sep 2007 08:37:28 GMT

Most everything looks normal. Oracle is using 740MB of RAM so there should be plenty to restore using frecover. Do you have frecover patched? It should look like thisa with the what command:

what /usr/sbin/frecover
io.c $Date: 2003/04/15 04:32:52 $Revision: r11.11/1 PATCH_11.11 (PHCO_28998)
$Revision: @(#) all CUP11.11_BL2003_0417_1 PATCH_11.11 PHCO_28998
Thu Apr 17 03:30:50 PDT 2003 $

Be sure to patch frecover if PHCO_28998 is not in the what string. The very latest patch is PHCO_36630 which you might install.

Re: frecover slow problem

ng_7 — Sat, 22 Sep 2007 01:58:13 GMT

try to update already, but problem persist.

what /usr/sbin/frecover
/usr/sbin/frecover:
io.c $Date: 2003/04/15 04:32:52 $Revision: r11.11/1 PATCH_11.11 (PHCO_28998)
vdi.c $Date: 2007/05/22 15:32:41 $Revision: r11.11/2 PATCH_11.11 (PHCO_36630)
$Revision: @(#) backup R11.11_BL2007_0618_1 PATCH_11.11 PHCO_36630

Re: frecover slow problem

ng_7 — Wed, 26 Sep 2007 03:36:50 GMT

hi, do you have any other idea on this ?

thanks

ng

Re: frecover slow problem

Bill Hassell — Wed, 26 Sep 2007 22:11:29 GMT

The only other question is about patches. When did you last patch your system with the QPK and HWE bundles?

Re: frecover slow problem

ng_7 — Wed, 26 Sep 2007 22:39:09 GMT

May I know how to check this, thanks

Re: frecover slow problem

Bill Hassell — Thu, 27 Sep 2007 18:21:24 GMT

swlist -l bundle | grep -i -e gold -e hwe

The date for these bundles are at the end of each line.

Re: frecover slow problem

ng_7 — Thu, 27 Sep 2007 19:25:47 GMT

db1:/# swlist -l bundle |grep -i -e gold -e hwe
GOLDAPPS11i B.11.11.0612.459 Applications Patches for HP-UX 11i v1, December 2006
GOLDBASE11i B.11.11.0612.459 Base Patches for HP-UX 11i v1, December 2006
HWEnable11i B.11.11.0612.458 Hardware Enablement Patches for HP-UX 11i v1, December 2006
db1:/#

Re: frecover slow problem

Bill Hassell — Thu, 27 Sep 2007 19:59:03 GMT

Do you have any network-based filesystems such as NFS or Samba/CIFS? You can see this with:

bdf -t nfs
bdf -t cifs