informix.html 54.9 KB
Newer Older
O'Reilly Media, Inc.'s avatar
O'Reilly Media, Inc. committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
</head>
<body>

<center><font face="TIMES"><font size=+3>Recovering Informix</font></font></center>

<br><font face="TIMES"></font>&nbsp;<font face="TIMES"><font size=-1>Recovering
Informix is much easier than recovering other databases. One reason is
that the commands to actually perform the recovery are simple---there is
only one argument for <i>ontape</i> and only two arguments for <i>onbar</i>.
This section covers just about any recovery scenario that you might find
yourself in, yet it's only 20 main steps.</font></font>
<p><font face="TIMES"><font size=-1>Another reason that Informix recoveries
are simple is that the sysmaster database, physical log, and logical log
are considered critical. In order to recover one of them, you have to recover
all of them. In Oracle, for instance, there are four or five different
recovery tactics that you can take, depending on which one of these objects
is damaged. With Informix, there is only one recovery tactic.</font></font>
<p><font face="TIMES"><font size=-1>The Informix recovery procedure does
not assume that you know why your database went down. It does assume that
you have been making backups via <i>ontape</i> or <i>onbar</i>. It also
assumes that if you are using <i>ontape</i>, you know which tapes or files
contain the latest level 0 and/or level 1 backups, as well as the location
of all logical log backups since your last physical backup. If you are
using <i>onbar</i>, this procedure assumes you know how to use your storage
manager well enough that you know how to respond to its prompts for any
media that may not be in an autochanger. In short, all media management
is up to you.</font></font>
<p><font size=-1><font face="TIMES">The examples below use <i>ontape</i>.
The example hostname is <i>curtis</i>, and the instance name is </font><font face="Courier">crash</font><font face="TIMES">.
The archives are being sent to disk files named <i>/informix/logical/crash/crash.level.level.Z</i>,
and continuous backups are being sent to a disk file named <i>/informix/logical/crash.log</i>.</font></font><font face="TIMES"><font size=-1></font></font>
<p><font face="TIMES"><font size=-1>You should start with Step 1, "Does
oninit work?"</font></font>
<center>
<p><map NAME="flowchrt"><area HREF="#Step19" SHAPE="RECT" COORDS="383,803,505,889"><area HREF="#Step17" SHAPE="RECT" COORDS="21,950,158,1070"><area HREF="#Step16" SHAPE="POLY" COORDS="26,844,93,902,156,844,90,793,89,793,26,844"><area HREF="#Step15" SHAPE="RECT" COORDS="538,660,669,748"><area HREF="#Step18" SHAPE="POLY" COORDS="382,704,446,652,507,706,445,755,382,704"><area HREF="#Step7" SHAPE="POLY" COORDS="26,575,26,574,93,523,155,576,91,626,26,575"><area HREF="#Step8" SHAPE="POLY" COORDS="204,574,208,574,270,521,330,577,267,628,204,574"><area HREF="#Step10" SHAPE="RECT" COORDS="383,533,505,618"><area HREF="#Step12" SHAPE="RECT" COORDS="537,532,666,620"><area HREF="#Step13" SHAPE="POLY" COORDS="648,431,710,379,773,430,711,485,648,431"><area HREF="#Step11" SHAPE="POLY" COORDS="483,430,483,431,549,377,607,432,546,482,483,430"><area HREF="#Step9" SHAPE="POLY" COORDS="323,429,389,377,389,377,450,432,388,481,388,480,323,429"><area HREF="#Step5" SHAPE="RECT" COORDS="145,360,274,447"><area HREF="#Step14" SHAPE="RECT" COORDS="659,208,757,295"><area HREF="#Step6" SHAPE="RECT" COORDS="506,208,624,292"><area HREF="#Step4" SHAPE="POLY" COORDS="321,250,386,197,447,252,385,302,385,302,321,250"><area HREF="#Step5" SHAPE="RECT" COORDS="106,232,234,320"><area HREF="#Step3" SHAPE="RECT" COORDS="420,67,537,158"><area HREF="#Step2" SHAPE="POLY" COORDS="284,62,223,115,284,165,348,113,284,62"><area HREF="#Step1" SHAPE="POLY" COORDS="29,112,92,60,153,116,93,166,29,112"></map><img SRC="informix.gif" NAME="flowchrt" USEMAP="#flowchrt" height=1106 width=797></center>
<b><font face="TIMES"><font size=+1></font></font></b>
<p><a NAME="Step1"></a><b><font face="TIMES"><font size=+1>Step 1: Does
oninit Work?</font></font></b>
<p><font face="TIMES"><font size=-1>The obvious first step in determining
if an instance is in need of recovery is to try and start the instance.
Do this by issuing the <i>oninit</i> command with no options. If it works,
it just returns the prompt to you. You could also see one of two errors.</font></font>
<dir><font face="Courier"><font size=-2>curtis $ oninit</font></font>
<p><font face="Courier"><font size=-2>WARNING: Cannot access configuration
file $INFORMIXDIR/etc/$<i>ONCONFIG</i>.</font></font></dir>
<font face="TIMES"><font size=-1>This error is pretty obvious. If you see
it, you are missing your configuration file.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If you see the error above, proceed
to Step 2.</font></font></dir>
<font face="Courier"><font size=-2>oninit: Cannot open chunk '/informix/rootdbs.dbf'.
errno = 2</font></font>
<p><font face="Courier"><font size=-2>oninit: Cannot open chunk '/informix/rootdbs_mirror.dbf'.
errno = 2</font></font>
<p><font face="Courier"><font size=-2>oninit: Fatal error in shared memory
initialization</font></font></dir>
<font face="TIMES"><font size=-1>If any of your critical dbspaces has damaged
or missing chunks, you may see an error like the one above. If all critical
dbspaces are mirrored, and only one-half of the mirror is damaged, you
do not see this error. It also does not appear if a non-critical dbspace
is damaged. This error appears only if <i>all</i> chunks in a <i>critical</i>
dbspace are damaged.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If you see an error like the one
above, proceed to Step 4. If you don't see either error, proceed to Step
7.</font></font></dir>
</dir>
<a NAME="Step2"></a><b><font face="TIMES"><font size=+1>Step 2: Is the
onconfig File Missing?</font></font></b>
<p><font face="TIMES"><font size=-1>The <i>oninit</i> utility uses the
<i>onconfig</i>
file to determine the basic information needed to start the instance. This
includes, but is not limited to, the following instance-specific information:</font></font>
<ul>
<li>
<font face="TIMES"><font size=-1>The location of the root dbspace</font></font></li>

<li>
<font face="TIMES"><font size=-1>The location of the physical log</font></font></li>

<li>
<font face="TIMES"><font size=-1>The SERVERNUM value</font></font></li>

<li>
<font face="TIMES"><font size=-1>The base address of shared memory</font></font></li>

<li>
<font face="TIMES"><font size=-1>Sqlhosts information</font></font></li>
</ul>

<dir>
<dir><font face="TIMES"><font size=-1>If the <i>onconfig</i> file is missing
or corrupted, proceed to Step 3. If this is not the reason the instance
would not start, proceed to Step 4.</font></font></dir>
</dir>
<a NAME="Step3"></a><b><font face="TIMES"><font size=+1>Step 3: Restore
or Recreate the onconfig File</font></font></b>
<p><font face="TIMES"><font size=-1>If you are running <i>onbar</i>, it
can automatically recreate the <i>onconfig</i> file. However, if this file
is the only one damaged, there's no need to do a full restore just to restore
this file. Restoring or recreating it is easy enough.</font></font>
<p><font face="TIMES"><font size=-1>If you are running <i>infback.sh</i>,
it makes a backup copy of the <i>onconfig</i> file before it changes it.
DBAs and other scripts often do the same. Look first to see if you have
such a backup copy. If not, try to restore the file from the nightly filesystem
backups. If you cannot find a backup copy, and cannot restore one from
backup, you will need to recreate it. If any of the following objects is
available, it will be easy:</font></font>
<ul>
<li>
<font face="TIMES"><font size=-1>The chunk (or its mirror) that contains
the root dbspace</font></font></li>

<li>
<font face="TIMES"><font size=-1>A level 0 or 1 archive created by <i>ontape</i>
on disk</font></font></li>

<li>
<font face="TIMES"><font size=-1>A level 0 or 1 archive created by <i>ontape</i>
on tape</font></font></li>
</ul>
<font face="TIMES"><font size=-1>To recreate the <i>onconfig</i> file from
the root dbspace chunk or an <i>ontape</i> archive on disk, run the following
command, where filename is the name of the chunk or archive on disk:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>strings <i>filename</i>|grep
'^[A-Z][A-Z_]*'</b> \</font></font>
<p><b><font face="Courier"><font size=-2>><i>$INFORMIX</i>/etc/<i>$</i>ONCONFIG</font></font></b></dir>
<font face="TIMES"><font size=-1>If you have only an archive available
on tape, the command is similar:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>dd if=<i>$TAPEDEV</i> bs=<i>$TAPEBLK</i>
\</b></font></font>
<p><b><font face="Courier"><font size=-2>| strings |grep '^[A-Z][A-Z_]*'
\</font></font></b>
<dir><b><font face="Courier"><font size=-2><i>> $INFORMIX</i>/etc/<i>$</i>ONCONFIG</font></font></b></dir>
</dir>
<font face="TIMES"><font size=-1>This creates an editable text file that
contains all the parameters and their current values. The <i>grep</i> command
does not completely remove extraneous lines, so you should edit it and
remove any lines that do not look like the following:</font></font>
<dir><font face="Courier"><font size=-2>PARAMETER value</font></font></dir>
<font size=-1><font face="TIMES">If you do not have one of these objects
available, you need to manually recreate the file. Copy the <i>onconfig.std</i>
file in <i>$INFORMIXDIR/etc</i> to the name of the <i>onconfig</i> file.
The values that you must change are </font><font face="Courier">ROOTNAME</font><font face="TIMES">,
</font><font face="Courier">ROOTPATH</font><font face="TIMES">,
</font><font face="Courier">DBSERVERNAME</font><font face="TIMES">,
</font><font face="Courier">SERVERNUM</font><font face="TIMES">,
and </font><font face="Courier">SHMBASE</font><font face="TIMES">. These
values will allow you to restore the instance.</font></font>
<p><a NAME="Step4"></a><b><font face="TIMES"><font size=+1>Step 4: Is there
an Inaccessible or a Critical Chunk?</font></font></b>
<p><font face="TIMES"><font size=-1>If an Informix instance will not start,
the most common cause is a missing or corrupt critical chunk. (If a non-critical
chunk is damaged the instance starts and records the problem to the online
log file.) The error that you receive may look something like the following:</font></font>
<dir><font face="Courier"><font size=-2>oninit: Cannot open chunk '/informix/rootdbs.dbf'.
errno = 2</font></font></dir>
<font face="TIMES"><font size=-1>According to <i>errno.h</i>, an "Error
2" means "No such file or directory." This means that the chunk, or the
symbolic link that Informix uses to refer to that chunk, is missing. Another
common error is 13, which means "Permission denied." This means that someone
other than Informix owns the device. Any error other than those usually
means that the physical file is all right, but the data within it is corrupted.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If the file is missing or its permissions
are wrong, proceed to Step 5. If not, proceed to Step 6.</font></font></dir>
</dir>
<a NAME="Step5"></a><b><font face="TIMES"><font size=+1>Step 5: Repair
or Replace the Missing Chunk</font></font></b>
<p><font face="TIMES"><font size=-1>This step is necessary only if the
physical file is somehow damaged. If it was a filesystem file, it might
be deleted or its permissions changed. If it was a raw device, the disk
drive could be damaged or missing, or its permissions could be wrong. Another
problem could be that you are using a symbolic link to the real chunk,
and the symbolic link was accidentally deleted.</font></font>
<p><font face="TIMES"><font size=-1>If the missing file is a symbolic link,
you simply need to restore or recreate the file in its original location.
The only difficulty part is that Informix doesn't tell you which file it
was symbolically linked to. Restoring the symbolic link from your regular
filesystem backups is probably the easiest answer. Another method would
be to consult any documentation that you may have about how you put the
instance together. (Restoring from backup is obviously much easier.)</font></font>
<p><font size=-1><font face="TIMES">If it is not a symbolic link, the damaged
file may be a filesystem file or raw device. If it is a filesystem file
and the filesystem itself is intact, simply recreate a new file with the
touch command. After doing so, make sure that the file is read/write for
the </font><font face="Courier">informix</font><font face="TIMES"> user
and </font><font face="Courier">informix</font><font face="TIMES"> group.
If the filesystem is not intact, you need to relocate the file. Hopefully,
you followed the common practice of using symbolic links to point to the
actual chunks. If you did, you can recreate the chunk file anywhere on
the system and just change the symbolic link to point to the new location.
If you did not, you need to make a symbolic link in the original location
to point to the new file.</font></font>
<p><font face="TIMES"><font size=-1>For example, assume that the filesystem
<i>/data1</i>
is destroyed, and it contained chunk <i>/data1/rootdbs.dbf</i>. However,
you set up the Informix instance to point directly to <i>/data1/rootdbs.dbf</i>,
instead of to a symbolic link to that chunk. You create a new file called
<i>rootdbs.dbf</i>
in <i>/data2</i>, but you have to tell <i>oninit</i> to use the new file.
You need to <i>unmount</i> <i>/data1</i> (although it probably is already)
and create a symbolic link in the old location with the following command:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>ln -s /data2/rootdbs.dbf /data1/rootdbs.dbf</b></font></font></dir>
<font face="TIMES"><font size=-1>This is, of course, a very bad solution
since repairing and remounting /data1 will overwrite the symbolic link.
If you have to do this, consult your IDS Adminstration Manual about permanently
relocating the file. (Use a symbolic link this time.)</font></font>
<p><font face="TIMES"><font size=-1>Before continuing, you may wish to
verify that all chunks are all right. If you don't have a complete list
of filenames, you can obtain them by running the <i>strings</i> command
on a root dbspace chunk or a <i>ontape</i> archive:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>zcat /informix/logical/crash/crash.level.1.Z
\</b></font></font>
<p><b><font face="Courier"><font size=-2>| strings | grep '^/'</font></font></b></dir>
<font face="TIMES"><font size=-1>Make sure that you have checked both of
the following conditions:</font></font>
<p><font face="TIMES"><font size=-1>Permissions</font></font>
<dir><font face="TIMES"><font size=-1>Ensure that someone didn't accidentally
change the ownership or permissions of any chunks. If you are using symbolic
links to point to the actual chunks, the only permissions that matter are
those for the final file to which the symbolic link is pointing. For example,
suppose that you have a symbolic link called <i>/informix/chunk1</i> that
points to <i>/dev/dsk/c0t0d0s5</i>. If you are running Solaris, and if
you run an <i>ls -l</i> on <i>/dev/dsk/c0t0d0s5</i>, you will find this:</font></font>
<dir><font face="Courier"><font size=-2>lrwxrwxrwx 1 root other 84 Nov
5 02:29 /dev/dsk/c0t0d0s5 -> ../..</font></font>
<p><font face="Courier"><font size=-2>/devices/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000</font></font>
<p><font face="Courier"><font size=-2>/esp@f,800000/sd@0,0:f</font></font></dir>
<font face="TIMES"><font size=-1>It is the permissions of <i><a href="mailto:sd@0,0:f">sd@0,0:f</a></i>
that matter, not the symbolic link /dev/dsk/c0t0d0s5. To verify its permissions,
run the following command:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>Ls -lL /dev/dsk/c0t0d0s5</b></font></font></dir>
<font size=-1><font face="TIMES">Adding the <i>-L</i> option causes it
to display the ownership and permissions of the source file, not of the
link. Make sure that both the owner and group are </font><font face="Courier">informix</font><font face="TIMES">,
and that the file is read/write for both the owner and the group.</font></font></dir>
<font face="TIMES"><font size=-1>Symbolic link</font></font>
<dir><font face="TIMES"><font size=-1>This problem usually happens when
the DBA is trying to "clean house." If you're using symbolic links to point
to the actual chunks, and someone deletes the symbolic link, you obviously
have a problem. If you are using symbolic links, make sure that you remake
the symbolic link instead of creating a chunk in its place.</font></font>
<dir><font face="TIMES"><font size=-1>If the instance is currently down
because a critical dbspace could not be opened, return to Step 1 and run
<i>oninit</i>
again. If the instance is already up and you were sent here by Step 8,
proceed to Step 9. If you have repaired or replaced any missing chunks,
and the instance still won't start, proceed to Step 6.</font></font></dir>
</dir>
<a NAME="Step6"></a><b><font face="TIMES"><font size=+1>Step 6: Performing
a Cold Restore</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>You should be performing this step
only if directed to do so by Step 5.</font></font></dir>
</dir>
<b><font face="TIMES"><font size=-1>Make sure you need this step</font></font></b>
<dir><font face="TIMES"><font size=-1>This is not a step to be taken lightly.
Depending on the size of your instance, a cold restore may take a considerable
amount of time. Please take a moment to verify that you really do need
to perform a restore; if you do, follow the appropriate section below.</font></font>
<dir><font face="TIMES"><font size=-1>Can't I just restore the critical
dbspaces?</font></font>
<p><font face="TIMES"><font size=-1>Both <i>ontape</i> and <i>onbar</i>
allow you to specify a list of dbspaces to restore. This even works with
critical dbspaces. However, if you restore just the critical dbspaces,
the restore leaves all other chunks in an "inconsistent" state, as specified
by the "I" flag that they display after the restore is done. Informix support
does have a tool that will change this flag to consistent, but your mileage
will vary on this one. If you are restoring a critical dbspace, you should
really restore the whole thing.</font></font></dir>
</dir>
<b><font face="TIMES"><font size=-1>Restoring with ontape</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>Make sure to remove the current logical
log "tape" prior to beginning a physical restore. If you're backing up
to disk, this means moving the file to a different location. If you're
backing up to tape, this means physically removing the current logical
log tape. When performing a physical restore with <i>ontape</i>, it asks
you if you want to back up the current log, and you should <i>always say
yes.</i> However, this performs an <i>ontape -a</i> backup, not an <i>ontape
-c</i> backup. Remember that the primary difference between these two options
is that <i>ontape -a</i> <i>overwrites</i> the "tape" currently in the
drive. <i>If it contains any logs other than the current log, they will
disappear forever.</i></font></font></dir>
</dir>
<font face="TIMES"><font size=-1>After removing the current logical log
tape or file from its current location, place the latest level 0 archive
in the device specified by <i>$TAPEDEV</i>. If you are backing up to disk,
this may require uncompressing and moving a file to the appropriate location.
If your backing up to tape, it involves placing the latest level 0 archive
in the tape drive. After doing so, execute the following command:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>ontape -r</b></font></font></dir>
<i><font face="TIMES"><font size=-1>Ontape</font></font> prompts you for
everything that it needs. You need to know if you have a level 1 or 2 backup,
since it will ask you that. You'll also need to know the location of all
logical log backups since the latest archive was taken.</i>
<dir>
<dir><i>Informix asks you if you want to back up the logs. Always say yes,
but make sure that you are giving it a fresh tape or file to back up to,
since it will overwrite it -- not append to it.</i></dir>
</dir>
<i>The following example was done with an instance that is archiving to
disk using infback.sh. Infback.sh now uses named pipes, so the value for
$TAPEDEV will be a named pipe (e.g., /informix/logical/crash.level.1.fifo)
that reflects the last level that was performed. Since infback.sh will
recreate the named pipe when it needs to, we will overwrite it with symbolic
links. The example instance also used rclogs.sh to continuously back up
the logical logs to disk. The value for $LTAPEDEV is /informix/logical/crash.log,
and when it switches logs, it copies them to /informix/logical/$ONCONFIG.year.month.day.hour.minute.second.</i>
<p><i>An ontape restore with archives on disk always requires more than
one window, and this section needs to show both windows below to fully
demonstrate the example. To reduce confusion, it uses a regular paragraph
like this one when switching windows. Since it still needs to explain the
reasoning behind certain commands or answers within a window, it uses this
font to do that. There is also a heading on each body of computer output
specifying either Restore Window or Alternate Window. The restore window
is the window where the ontape -r command is being run, and the alternate
window will be the window where we perform other commands. We will start
with Figure 13-20, the restore window.</i>
<dir><i><font face="Courier"><font size=-2>[Restore Window]</font></font></i>
<p><i><font face="Courier"><font size=-2>#The first thing that we need
to do is</font></font></i>
<p><i><font face="Courier"><font size=-2>#uncompress the archive files</font></font></i>
<p><i>curtis$ <b>uncompress /informix/logical/crash/crash.level.*.Z</b></i>
<p><i>curtis$ <b>ls /informix/logical/crash</b></i>
<p><i>crash.level.0 crash.level.1</i>
<p><i>#Now we need to remove the named pipe and replace it with a</i>
<p><i>#symbolic link</i>
<p><i>#to the actual backup file</i>
<p><i>curtis$ <b>rm /informix/crash.level.0.fifo</b></i>
<p><i>curtis$ <b>ln -s /informix/logical/crash/crash.level.0 /informix/crash.level.0.fifo</b></i>
<p><i>#Now we can begin the restore</i>
<p><i>curtis$ <b>ontape -r</b></i>
<p><i>Please mount tape 1 on /informix/logical/crash/crash.level.0 and
press Return to continue ...</i>
<p><i>Archive Tape Information</i>
<p><i>Tape type: Archive Backup Tape</i>
<p><i>Online version: INFORMIX-OnLine Version 7.23.UC4</i>
<p><i>Archive date: Thu Jan 21 00:57:14 1999</i>
<p><i>User id: informix</i>
<p><i>Terminal id: ?</i>
<p><i>Archive level: 0</i>
<p><i>Tape device: /informix/crash.level.0.fifo</i>
<p><i>Tape blocksize (in k): 16</i>
<p><i>Tape size (in k): 1024000</i>
<p><i>Tape number in series: 1</i>
<p><i>Spaces to restore:</i>
<p><i>1 [rootdbs ]</i>
<p><i>2 [plogdbs ]</i>
<p><i>3 [llogdbs ]</i>
<p><i>4 [testdbs ]</i>
<p><i>Archive Information</i>
<p><i>INFORMIX-OnLine Copyright(C) 1986-1995 Informix Software, Inc.</i>
<p><i>Initialization Time 03/04/98 20:08:25</i>
<p><i>System Page Size 2048</i>
<p><i>Version 4</i>
<p><i>Archive CheckPoint Time 01/21/99 00:57:17</i>
<p><i>Dbspaces</i>
<p><i>number flags fchunk nchunks flags owner name</i>
<p><i>1 2 1 1 M informix rootdbs</i>
<p><i>2 2 2 1 M informix plogdbs</i>
<p><i>3 2 3 1 M informix llogdbs</i>
<p><i>4 1 4 1 N informix testdbs</i>
<br>&nbsp;
<br>&nbsp;
<p><i>Chunks</i>
<p><i>chk/dbs offset size free bpages flags pathname</i>
<p><i>1 1 0 10000 9051 PO- /informix/rootdbs.dbf</i>
<p><i>1 1 0 10000 0 MO- /informix/rootdbs_mirror.dbf</i>
<p><i>2 2 0 5000 2447 PO- /informix/physlog.dbf</i>
<p><i>2 2 0 5000 0 MO- /informix/physlog_mirror.dbf</i>
<p><i>3 3 0 5000 3447 PO- /informix/logiclog.dbf</i>
<p><i>3 3 0 5000 0 MO- /informix/logiclog_mirror.dbf</i>
<p><i>4 4 0 500 191 PO- /informix/testdbs.dbf</i>
<p><i>#Ontape displays all this information to you so that you know</i>
<p><i>#that this is the right tape to restore the right instance.</i>
<p><i>#It doesn't actually do</i>
<p><i>#anything until you respond "y" to the next question.</i>
<p><i>Continue restore? (y/n)<b>y</b></i>
<p><i>#Always say "YES" to this next question.</i>
<p><i>Do you want to back up the logs? (y/n)<b>y</b></i>
<p><i>Please mount tape 1 on /informix/logical/crash.log and press Return
to continue ...</i>
<p><i>Would you like to back up any of logs 65 - 67? (y/n) <b>y</b></i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-20: Starting an ontape
restore</font></font></i></dir>
</dir>
<i>This next section is from another window. We need to move the old logical
log "tape" out of the way so that the salvaging of the current log does
not overwrite it. In the example in Figure 13-21, we will use the same
naming convention as the other files.</i>
<dir><i><font face="Courier"><font size=-2>[Alternate Window]</font></font></i>
<p><i>curtis$ <b>cp crash.log crash.log.1999.01.21.17.04.00</b></i>
<p><i>curtis$ <b>compress crash.log.1999.01.21.15.05.16</b></i>
<p><i>curtis$ <b>ls -l crash.log.1999.01.21*</b></i>
<p><i>total 2424</i>
<p><i>-rw-rw---- 1 informix informix 73961 Jan 21 01:12 crash.log.1999.01.21.01.13.02.Z</i>
<p><i>-rw-rw---- 1 informix informix 1949 Jan 21 01:13 crash.log.1999.01.21.01.14.08.Z</i>
<p><i>-rw-rw---- 1 informix informix 557056 Jan 22 17:04 crash.log.1999.01.22.17:04:00.Z</i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-21: Preparing disk-based
logical log backups</font></font></i></dir>
</dir>
<i>Once we've copied the "tape" to another location, it is safe to tell
Informix to salvage the current logical log. Note in Figure 13-22 that
when it asks for the oldest log that we would like to back up, we answer
with the oldest number available. (It never hurts to have too many logical
log backups. If we were to answer "66," what would happen if the restore
needed log 65 and it had not been backed up, or its backup had been damaged?
We would be out of luck, that’s what.</i>
<dir><i><font face="Courier"><font size=-2>[Restore Window]</font></font></i>
<p><i>Logical logs 65 - 67 may be backed up.</i>
<p><i>Enter the id of the oldest log that you would like to backup? <b>65</b></i>
<p><i>Please label this tape as number 1 in the log tape sequence.</i>
<p><i>This tape contains the following logical logs:</i>
<p><i>1 - 67</i>
<p><i>Log salvage is complete, continuing restore of archive.</i>
<p><i>#we do have a level one archive, so when it asks if we have one,</i>
<p><i>#we will answer "yes."</i>
<p><i>Restore a level 1 archive (y/n) <b>y</b></i>
<p><i>Ready for level 1 tape</i>
<br>&nbsp;
<br>&nbsp;
<dir><i><font face="TIMES"><font size=-1>Figure 13-22: Backing up the current
logical logs</font></font></i></dir>
</dir>
<i>You may recall that prior to beginning the restore, we created a symbolic
link from the level 0 archive on disk to the location that Informix expects
the archive to be. Now that we are "swapping tapes," we need to remove
that link and create another one that points to the level 1 backup. (The
commands in Figure 13-23 are obviously being done in another window.)</i>
<dir><i><font face="Courier"><font size=-2>[Alternate Window]</font></font></i>
<p><i>curtis$ <b>rm /informix/crash.level.0.fifo</b></i>
<p><i>curtis$ <b>ln -s /informix/logical/crash/crash.level.1 /informix/crash.level.0.fifo</b></i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-23: Simulating a tape
swap</font></font></i></dir>
</dir>
<i>Now that we have swapped tapes, we can respond to the prompt shown in
Figure 13-24.</i>
<dir><i><font face="Courier"><font size=-2>[Restore Window]</font></font></i>
<p><i>Please mount tape 1 on /informix/logical/crash/crash.level.0 and
press Return to continue ...</i>
<p><i>Archive Tape Information</i>
<p><i>Tape type: Archive Backup Tape</i>
<p><i>Online version: INFORMIX-OnLine Version 7.23.UC4</i>
<p><i>Archive date: Thu Jan 21 01:10:13 1999</i>
<p><i>User id: informix</i>
<p><i>Terminal id: ?</i>
<p><i>Archive level: 1</i>
<p><i>Tape device: /informix/crash.level.1.fifo</i>
<p><i>Tape blocksize (in k): 16</i>
<p><i>Tape size (in k): 1024000</i>
<p><i>Tape number in series: 1</i>
<p><i>#We do not have a level to archive, so we will answer no to</i>
<p><i>#following prompt.</i>
<p><i>Restore a level 2 archive (y/n) <b>n</b></i>
<p><i>#We do want to restore log tapes, though...</i>
<p><i>Do you want to restore log tapes? (y/n)<b>y</b></i>
<p><i>Roll forward should start with log number 65</i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-24: Responding to ontape’s
prompts</font></font></i></dir>
</dir>
<i>Again, we must move over to the other window and prepare the logical
log "tape." First, we move the salvage logs to an appropriately named file
and compress it. Then we use the log concatenation method discussed in
the previous sidebar. Since the logs are compressed, in Figure 13-25 we
create a single concatenated log using zcat.</i>
<dir><i><font face="Courier"><font size=-2>[Alternate Window]</font></font></i>
<p><i>curtis$ <b>mv crash.log crash.log.1999.01.21.18.00.00</b></i>
<p><i>curtis$ <b>compress crash.log.1999.01.21.18.00.00</b></i>
<p><i>curtis$ <b>ls -l crash.log.1999.01.2*</b></i>
<p><i>total 2424</i>
<p><i>-rw-rw---- 1 informix informix 73961 Jan 21 01:12 crash.log.1999.01.21.01.13.02.Z</i>
<p><i>-rw-rw---- 1 informix informix 1949 Jan 21 01:13 crash.log.1999.01.21.01.14.08.Z</i>
<p><i>-rw-rw---- 1 informix informix 557056 Jan 22 17:04 crash.log.1999.01.22.17:04:00.Z</i>
<p><i>-rw-rw---- 1 informix informix 557056 Jan 22 18:00 crash.log.1999.01.22.18.00.00.Z</i>
<p><i>curtis$ <b>zcat *1999* >crash.log</b></i>
<p><i>curtis$ <b>chmod 664 * crash.log</b></i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-25: Creating one large
logical log backup</font></font></i></dir>
</dir>
<i>Now that we have created the single log, we can respond to the following
prompt in Figure 13-26.</i>
<dir><i><font face="Courier"><font size=-2>[Restore Window]</font></font></i>
<p><i>Please mount tape 1 on /informix/logical/crash.log and press Return
to continue ...</i>
<p><i>#Since we put all logs into this single log, there are no</i>
<p><i>#more logs to restore.</i>
<p><i>Do you want to restore another log tape? (y/n)<b>n</b></i>
<p><i>Program over.</i>
<p><i>#The next step is very important. You must bring the</i>
<p><i>#instance online when you are done, or you will</i>
<p><i>#need to do the restore all over again.</i>
<p><i>curtis$ <b>onmode -m</b></i>
<dir><i><font face="TIMES"><font size=-1>Figure 13-26: Completing the restore
and starting the instance</font></font></i>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p><i>Make sure that you use onmode -m to bring the instance online after
doing a cold restore. If you do not, you will need to completely redo the
restore if you stop and start the instance before doing so.</i></dir>
</dir>
<b><i>Restoring with onbar</i></b>
<p><i>The first and simplest recovery with onbar is to enter onbar -r.
This specifies to do a complete restore of any offline dbspaces. It automatically
performs the following three steps for you:</i>
<ol>
<li>
<i>onbar -l -s (salvage the logical log).</i></li>

<li>
<i>onbar -r -p [-w] (complete physical restore, which reads the archive
only)</i></li>

<li>
<i>onbar -r -l (complete logical restore, which reads all available logical
logs)</i></li>
</ol>
<i>You may also add an optional -w flag (onbar -r -w) that specifies using
the latest whole backup when performing the restore. If you have not been
performing -w backups, then you cannot use -w on the restore. If you have
been using -w on your backups, then you can use the same option on the
restore. You also have the option of not using the -w option on the restore,
even if you did use it to back up.</i>
<p><i>Unlike ontape, you do not even need to move files around or swap
tapes if you have an autochanger. It automatically retrieves the appropriate
volumes that it needs to write to or read from. Even if you do not have
an autochanger, it prompts you for the appropriate tapes by name.</i>
<p><i>You also have the option of performing the three steps by yourself.
This allows you to use a number of flags to do different kinds of restores
based on your needs of the moment. The first thing you need to do, though,
is issue the onbar -l -s command to salvage any logical logs that have
not been backed up.</i>
<p><i>After doing that, you have a number of options when performing the
physical and logical restores. (As started earlier, a physical restore
is one that just reads the archive tape. It does not apply any logical
logs. Applying the logical logs is called the logical restore. The following
onbar command represents your options when beginning the physical restore.
Please note the grouping of the options. The -p, -n and -t options are
mutually exclusive, and so are the -w, dbspace_list and noflags options.</i>
<dir><font face="Courier"><font size=-2>$ <b>onbar -r \</b></font></font>
<p><font face="Courier"><font size=-2>[ <b>-p</b> | <b>-n <i>xxx</i></b>
| <b>-t <i>time</i> </b>] [ <b>-w</b> | <b><i>dbspace_list</i></b> | <b><i>noflags</i></b>
]</font></font></dir>
<font face="TIMES"><font size=-1>Here is a listing of the various options
and how they affect the restore:</font></font>
<p><i><font face="TIMES"><font size=-1>-p</font></font></i>
<dir><font face="TIMES"><font size=-1>Adding the <i>-p</i> option to the
<i>onbar
-r</i> command tells it to perform <i>only the physical restore</i>. If
you use this option, you need to run the <i>onbar -r -l</i> command to
perform the logical restore. If you do not specify this option, <i>onbar</i>
performs both a physical and a logical restore.</font></font></dir>
<font face="TIMES"><font size=-1><i>-n xxx </i>or <i>-t time</i></font></font>
<dir><font face="TIMES"><font size=-1>If you do not specify <i>-p</i>,
you can also use these flags to decide how the logical restore is performed.
For details on these flags, see the following logical restore section.</font></font></dir>
<i><font face="TIMES"><font size=-1>-w</font></font></i>
<dir><font face="TIMES"><font size=-1>This specifies to <i>use the latest
whole backup</i> when restoring the database. Although using this flag
will perform a restore of the whole database, this flag is actually telling
<i>onbarwhich
backup to use</i>, not what kind of restore to do. The reason this flag
is here is that if you do restore from a whole backup, you have the option
of <i>not</i> doing a logical restore, since you have restored the database
to a consistent point in time. (This option is not available to you if
you have not been making backups with the <i>-w</i> option.)</font></font></dir>
<i><font face="TIMES"><font size=-1>dbspace_list</font></font></i>
<dir><font face="TIMES"><font size=-1>If you do not use the <i>-w</i> option,
you can optionally list the dbspaces that <i>onbar</i> should recover,
separated by white space.</font></font></dir>
<i><font face="TIMES"><font size=-1>noflags</font></font></i>
<dir><font face="TIMES"><font size=-1>This is actually just a placeholder
to demonstrate what would happen if you used no other flags at all. If
you enter <i>onbar -r</i> or <i>onbar -p</i> <i>without </i>specifying
<i>-w</i>
or a list of dbspaces to recover, it automatically detects and recovers
any dbspaces that are offline. The noflags option, as described here, is
meant to reiterate the fact that you do not have to specify the
<i>-w</i>
flag to get a complete restore. The -w flag specifies the restore's
<i>source</i>,
not its <i>destination</i>.</font></font></dir>
<font face="TIMES"><font size=-1>If you specified just a physical restore,
you may now perform the logical restore. When doing so, you have three
options:</font></font>
<p><i><font face="TIMES"><font size=-1>onbar -r -l</font></font></i>
<dir><font face="TIMES"><font size=-1>This is the default method, and performs
a logical restore using all logical logs that were created since the latest
archive.</font></font></dir>
<i><font face="TIMES"><font size=-1>onbar -r -l -n lognumber</font></font></i>
<dir><font face="TIMES"><font size=-1>If you know the last log that you
wish to use, you may use this option. You may specify the last log that
<i>onbar</i>
should read using <i>-n lognumber</i>.</font></font></dir>
<i><font face="TIMES"><font size=-1>onbar -r -l -t time</font></font></i>
<dir><font face="TIMES"><font size=-1>You've been waiting for this one.
You know that you accidentally deleted a major table at 14:02. You would
like to replay all transactions <i>except that one.</i> You may tell <i>onbar</i>
to do this using the new <i>-t</i> <i>time</i> option. (In the previous
deleted table example, you would probably enter <i>onbar -r -l 14:00</i>.)</font></font>
<dir><font face="TIMES"><font size=-1>Make sure that you use <i>onmode
-m</i> to bring the instance online after doing a cold restore. If you
do not bring the instance online with onmode –m before the next time you
stop and start the instance, you will need to completely redo the restore</font></font></dir>
</dir>
<font face="TIMES"><font size=-1>In summary, an <i>onbar</i> restore offers
you the same simplicity as an <i>ontape</i> restore, since both have the
all-encompassing <i>-r</i> option that means to do a complete physical
and logical restore. However, if you need extra options like point-in-time
or point-in-log restores, they are available. It also has the added benefit
of working with your storage manager so that you no longer have to worry
about what tape has what backup. If you have not begun to look at <i>onbar</i>,
perhaps now is the time to start.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>Nine out of every 10 restores will
end right here. To make sure that everything is okay, return to step 1
and restart the instance <i>after first bringing it online with onmode
-m</i>.</font></font></dir>
</dir>
<a NAME="Step7"></a><b><font face="TIMES"><font size=+1>Step 7: Are there
Errors in the Online Log?</font></font></b>
<p><font face="TIMES"><font size=-1>Perhaps the instance started on your
first try. Perhaps you needed to do a cold restore in order to get it started.
The next thing to do would be to check the online log for any errors. Examples
of the types of errors you may see are shown in Figure 13-27:</font></font>
<dir><font face="Courier"><font size=-2>23:27:34 Assert Failed: WARNING!
pthdrpage:ptalloc:bad bfget</font></font>
<p><font face="Courier"><font size=-2>23:27:34 Who: Session(7, informix@curtis,
0, 169149316)</font></font>
<p><font face="Courier"><font size=-2>Thread(13, fast_rec, a12ccd8, 1)</font></font>
<p><font face="Courier"><font size=-2>23:27:34 Results: Cannot use TBLSpace
page for TBLSpace 4194305</font></font>
<p><font face="Courier"><font size=-2>23:27:34 Action: Run 'oncheck -pt
4194305'</font></font>
<p><font face="Courier"><font size=-2>23:27:34 See Also: /tmp/af.d79e5</font></font>
<p><font face="Courier"><font size=-2>23:27:34 Cannot Open DBspace 4.</font></font>
<dir><i><font face="TIMES"><font size=-1>Figure 13-27: Example errors in
the online log</font></font></i></dir>
</dir>
<i>If you see any errors like this, you should run an onstat -d to see
which chunk is having a problem:</i>
<dir><font face="Courier"><font size=-2>Chunks</font></font>
<p><font face="Courier"><font size=-2>address chk/dbs offset size free
bpages flags pathname</font></font>
<p><i><font face="Courier"><font size=-2># Output abbreviated...</font></font></i>
<p><font face="Courier"><font size=-2>a12a508 4 4 0 500 191 PD- /informix/testdbs.dbf</font></font></dir>
<font face="TIMES"><font size=-1>The flags above show you that the <i>/informix/testdbs.dbf
</i>chunk
is down. What you need to find out now is why it is down.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If you start the instance and there
are no errors in the online log, then proceed to Step 16. If there are
errors in the log, proceed to Step 8.</font></font></dir>
</dir>
<a NAME="Step8"></a><b><font face="TIMES"><font size=+1>Step 8: Is There
an Inaccessible Non-Critical Chunk?</font></font></b>
<p><font face="TIMES"><font size=-1>If <i>oninit</i> is able to access
all critical chunks, it brings the instance online. If any non-critical
chunks are inaccessible, it just logs the problem in the online log. If,
after checking the online log and running an <i>onstat -d</i>, you have
verified that a non-critical chunk is inaccessible to Informix, you need
to repair or replace it.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If a non-critical chunk is inaccessible,
return to Step 5. If you have verified that the problem chunk is now accessible
and has the correct permissions, proceed to Step 10.</font></font></dir>
</dir>
<a NAME="Step9"></a><b><font face="TIMES"><font size=+1>Step 9: Is There
a Corrupted Non-Critical Chunk?</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>You should be performing this step
only if directed to do so by Steps 5 or 8.</font></font></dir>
</dir>
<b><font face="TIMES"><font size=-1>You might not need a restore</font></font></b>
<p><font face="TIMES"><font size=-1>The best way to find out if your non-critical
chunks are corrupted is to try to bring them online. In order to be able
to do that, the following conditions must be true:</font></font>
<ul>
<li>
<font face="TIMES"><font size=-1>You were sent to this step because the
instance started, but there were errors in the online log</font></font></li>

<li>
<font face="TIMES"><font size=-1>One or more chunks is currently marked
down</font></font></li>

<li>
<font face="TIMES"><font size=-1>The reason it was marked down was that
<i>oninit</i>
couldn't access it</font></font></li>

<li>
<font face="TIMES"><font size=-1>The access problem was due to bad permissions
or a deleted symbolic link</font></font></li>

<li>
<font face="TIMES"><font size=-1>Its permissions are now ok, or the symbolic
link was recreated</font></font></li>
</ul>
<font face="TIMES"><font size=-1>If all these conditions are true, you
can probably save yourself a restore by bringing the dbspaces online using
<i>onspaces</i>.
Run the following command for each chunk that was marked down:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>onspaces -s <i>dbspacename</i>
-p <i>chunkname</i> -o <i>offset</i> -O</b></font></font>
<p><font face="Courier"><font size=-2>Warning: Bringing chunk back online.</font></font>
<p><font face="Courier"><font size=-2>Do you really want to continue? (y/n)<b>y</b></font></font>
<p><font face="Courier"><font size=-2>Verifying physical disk space, please
wait ...</font></font>
<p><font face="Courier"><font size=-2>Chunk status successfully changed.</font></font></dir>
<font face="TIMES"><font size=-1>If you see successful messages like this
one, you won't even need to do a restore. If it complains that the chunk
is inconsistent, you have to do a restore to bring it to a consistent state.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If you were able to bring all down
dbspaces online, proceed to Step 11. If not, proceed to Step 10 to restore
them.</font></font></dir>
</dir>
<a NAME="Step10"></a><b><font face="TIMES"><font size=+1>Step 10. Perform
a dbspace Restore</font></font></b>
<p><font face="TIMES"><font size=-1>There isn't much that can be said in
this step that wasn't already covered in Step 6. However, there are a few
differences between the restore discussed in Step 6 and this one:</font></font>
<ul>
<li>
<font face="TIMES"><font size=-1>The instance may be left online</font></font></li>

<li>
<font face="TIMES"><font size=-1>Only the affected dbspaces need to be
taken offline, and the recovery program will do that for you</font></font></li>

<li>
<font face="TIMES"><font size=-1>You will be listing specific dbspaces
to recover</font></font></li>

<li>
<font face="TIMES"><font size=-1>You will not be asked to back up the logical
logs</font></font></li>
</ul>
<font face="TIMES"><font size=-1>Read Step 6 in detail, then run one of
the following commands:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>ontape -r -D <i>dbspace dbspace</i></b><i>#Will
recovery any dbspaces</i></font></font>
<p><font face="Courier"><font size=-2>$ <b>onbar -r</b> <i>#Will recover
all down dbspaces</i></font></font>
<p><font face="Courier"><font size=-2>$ <b>onbar -r <i>dbspace</i></b><i>#Will
recover any dbspaces listed</i></font></font></dir>
<font face="TIMES"><font size=-1>Both <i>onbar</i> and <i>ontape</i> prompt
you with the same standard questions. The main differences are that you
may be warned that the affected dbspaces will be taken offline, and you
will not be asked the "Do you want to back up the logs?" question. A sample
output from an <i>ontape</i> restore can be found in Figure 13-28:</font></font>
<dir><font face="Courier"><font size=-2>curtis$ <b>onstat -d|grep testdbs.dbf</b></font></font>
<p><font face="Courier"><font size=-2>a12a508 4 4 0 500 191 PD- /informix/testdbs.dbf</font></font>
<p><font face="Courier"><font size=-2>curtis$ <b>ontape -r -D testdbs</b></font></font>
<p><font face="Courier"><font size=-2>DBspace 'testdbs' is online; restoring
'testdbs' will bring all chunks</font></font>
<p><font face="Courier"><font size=-2>comprising the DBspace OFFLINE and
will terminate all active</font></font>
<p><font face="Courier"><font size=-2>transactions and queries accessing
the DBspace.</font></font>
<p><font face="Courier"><font size=-2>OK to continue?<b>y</b></font></font>
<p><font face="Courier"><font size=-2>Please mount tape 1 on /informix/logical/crash/crash.level.0
and press Return to continue ...</font></font>
<p><font face="Courier"><font size=-2>Archive Tape Information</font></font>
<p><font face="Courier"><font size=-2>Tape type: Archive Backup Tape</font></font>
<p><font face="Courier"><font size=-2>Online version: INFORMIX-OnLine Version
7.23.UC4</font></font>
<p><font face="Courier"><font size=-2>Archive date: Thu Jan 21 00:57:14
1999</font></font>
<p><font face="Courier"><font size=-2>User id: informix</font></font>
<p><font face="Courier"><font size=-2>Terminal id: ?</font></font>
<p><font face="Courier"><font size=-2>Archive level: 0</font></font>
<p><font face="Courier"><font size=-2>Tape device: /informix/crash.level.0.fifo</font></font>
<p><font face="Courier"><font size=-2>Tape blocksize (in k): 16</font></font>
<p><font face="Courier"><font size=-2>Tape size (in k): 1024000</font></font>
<p><font face="Courier"><font size=-2>Tape number in series: 1</font></font>
<p><font face="Courier"><font size=-2>Continue restore? (y/n)<b>y</b></font></font>
<p><font face="Courier"><font size=-2>Spaces to restore:1 [testdbs ]</font></font>
<p><font face="Courier"><font size=-2>Restore a level 1 archive (y/n) <b>n</b></font></font>
<p><font face="Courier"><font size=-2>Do you want to restore log tapes?
(y/n)<b>y</b></font></font>
<p><font face="Courier"><font size=-2>Roll forward should start with log
number 65</font></font>
<p><font face="Courier"><font size=-2>Please mount tape 1 on /informix/logical/crash.log
and press Return to continue ...</font></font>
<p><font face="Courier"><font size=-2>Do you want to restore another log
tape? (y/n)<b>n</b></font></font>
<p><font face="Courier"><font size=-2>Program over.</font></font>
<p><font face="Courier"><font size=-2>curtis$ <b>onstat -d|grep testdbs.dbf</b></font></font>
<p><font face="Courier"><font size=-2>a12a508 4 4 0 500 191 PO- /informix/testdbs.dbf</font></font>
<dir><i><font face="TIMES"><font size=-1>Figure 13-28: Sample ontape output</font></font></i></dir>
</dir>
<i>Once the restore of all down dbspaces is complete, they will be brought
online.</i>
<dir>
<dir><i>Once all down dbspaces are restored and online, proceed to Step
11.</i></dir>
</dir>
<a NAME="Step11"></a><b><font face="TIMES"><font size=+1>Step 11: Are there
Wrong Values in the onconfig File?</font></font></b>
<p><font face="TIMES"><font size=-1>If you were forced to use an old <i>onconfig</i>
file backup, or create one from scratch, you may have some potentially
wrong values. Depending on which values are wrong, they may prevent the
instance from operating properly. If so, <i>oninit</i> logs them in the
online log.</font></font>
<dir><font face="Courier"><font size=-2>02:13:58 <i>Onconfig</i> parameter
LTAPEBLK modified from 32 to 16.</font></font>
<p><font face="Courier"><font size=-2>02:14:46 <i>Onconfig</i> parameter
MIRROROFFSET modified from 1 to 0</font></font>
<dir><font face="TIMES"><font size=-1>If you see any errors like this,
proceed to Step 12. If not, then proceed to Step 13.</font></font></dir>
</dir>
<a NAME="Step12"></a><b><font face="TIMES"><font size=+1>Step 12: Change
the Bad Values in the onconfig File</font></font></b>
<p><font size=-1><font face="TIMES">This one is about as easy as they come.
Change any bad values in the <i>onconfig</i> file back to their original
values. For example, if you saw the errors displayed in Step 11, you need
to change </font><font face="Courier">LTAPEBLK</font><font face="TIMES">
to 32 and </font><font face="Courier">MIRROROFFSET</font><font face="TIMES">
to 1. Unfortunately, most of these values are read only at startup.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>Once you have changed any incorrect
values, proceed to Step 13.</font></font></dir>
</dir>
<a NAME="Step13"></a><b><font face="TIMES"><font size=+1>Step 13: Ensuring
that the Instance will Restart</font></font></b>
<p><font face="TIMES"><font size=-1>If you changed any values in Step 12,
you need to restart the instance to have oninit read the new values. Also,
depending on the number of steps that you had to follow to get to this
step, you may want to make sure that everything will start correctly the
<i>next</i>
time. The only way to be sure of that is to restart the instance now.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If you wish to restart the instance,
proceed to Step 14. If not, proceed to Step 15.</font></font></dir>
</dir>
<a NAME="Step14"></a><b><font face="TIMES"><font size=+1>Step 14: Taking
the Instance Offline</font></font></b>
<p><font face="TIMES"><font size=-1>If you had to do any restores to get
to this step, make sure that you bring the instance online before you take
it offline again. To make sure that it is online, run the following command:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>oninit -</b></font></font>
<p><font face="Courier"><font size=-2>INFORMIX-OnLine Version 7.23.UC4
-- On-Line -- Up 00:00:29 -- 8976 Kbytes</font></font></dir>
<font face="TIMES"><font size=-1>If you see the above output, then the
instance was brought online. If you see the output below, you need to bring
the instance online by running the command <i>onmode -m</i>.</font></font>
<dir><font face="Courier"><font size=-2>INFORMIX-OnLine Version 7.23.UC4
-- Quiescent -- Up 00:01:17 -- 8976 Kbytes</font></font></dir>
<font face="TIMES"><font size=-1>Once you are sure that the instance is
online, you can take it offline:</font></font>
<dir><font face="Courier"><font size=-2>$ <b>onmode -ky</b></font></font>
<dir><font face="TIMES"><font size=-1>Once you have done so, return to
Step 1.</font></font></dir>
</dir>
<a NAME="Step15"></a><b><font face="TIMES"><font size=+1>Step 15: Confirming
that dbspaces and Chunks are Online</font></font></b>
<p><font face="TIMES"><font size=-1>If you don't restart the database,
you should make doubly sure that all dbspaces and chunks are online. To
do so, run the command <i>onstat –d</i>, as shown in Figure 13-29:</font></font>
<dir><font face="Courier"><font size=-2>curtis$ <b>onstat -d</b></font></font>
<p><font face="Courier"><font size=-2>INFORMIX-OnLine Version 7.23.UC4
-- On-Line -- Up 00:06:45 -- 8976 Kbytes</font></font>
<p><font face="Courier"><font size=-2>Dbspaces</font></font>
<p><font face="Courier"><font size=-2>address number flags fchunk nchunks
flags owner name</font></font>
<p><font face="Courier"><font size=-2>a12a100 1 2 1 1 M informix rootdbs</font></font>
<p><font face="Courier"><font size=-2>a12a790 2 2 2 1 M informix plogdbs</font></font>
<p><font face="Courier"><font size=-2>a12a800 3 2 3 1 M informix llogdbs</font></font>
<p><font face="Courier"><font size=-2>a12a870 4 1 4 1 N informix testdbs</font></font>
<p><font face="Courier"><font size=-2>4 active, 2047 maximum</font></font>
<p><font face="Courier"><font size=-2>Chunks</font></font>
<p><font face="Courier"><font size=-2>address chk/dbs offset size free
bpages flags pathname</font></font>
<p><font face="Courier"><font size=-2>a12a170 1 1 0 10000 9307 PO- /informix/rootdbs.dbf</font></font>
<p><font face="Courier"><font size=-2>a12a248 1 1 0 10000 0 MO- /informix/rootdbs_mirror.dbf</font></font>
<p><font face="Courier"><font size=-2>a12a358 2 2 0 5000 2447 PO- /informix/physlog.dbf</font></font>
<p><font face="Courier"><font size=-2>a12a5e0 2 2 0 5000 0 MO- /informix/physlog_mirror.dbf</font></font>
<p><font face="Courier"><font size=-2>a12a430 3 3 0 5000 3447 PO- /informix/logiclog.dbf</font></font>
<p><font face="Courier"><font size=-2>a12a6b8 3 3 0 5000 0 MO- /informix/logiclog_mirror.dbf</font></font>
<p><font face="Courier"><font size=-2>a12a508 4 4 0 500 191 PO- /informix/testdbs.dbf</font></font>
<p><font face="Courier"><font size=-2>4 active, 2047 maximum</font></font>
<dir><i><font face="TIMES"><font size=-1>Figure 13-29: A sample onstat
output</font></font></i></dir>
</dir>
<i>Check the flags column in the Dbspaces section for flags P, L, or R.
Also check the flags column of the Chunks section for flags D or I. The
meanings of these flags are:</i>
<p><i>P</i>
<dir><i>The dbspace has been physically recovered and is awaiting logical
recovery.</i></dir>
<i>L</i>
<dir><i>The dbspace is being logically recovered.</i></dir>
<i>R</i>
<dir><i>The dbspace is being physically recovered.</i></dir>
<i>D</i>
<dir><i>The chunk is down.</i></dir>
<i>I</i>
<dir><i>The chunk is in an inconsistent state.</i>
<dir><i>Once you know if there are any of these flags, proceed to step
18.</i></dir>
</dir>
<a NAME="Step16"></a><b><font face="TIMES"><font size=+1>Step 16: Recovering
a Deleted Table or Database</font></font></b>
<p><font face="TIMES"><font size=-1>Perhaps the instance started OK, but
there is a different problem. If a DBA accidentally deleted a dbspace,
or a user accidentally deleted an important table, there is really only
one way to recovery that -- a point-in-time restore.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>If you need a point-in-time restore,
proceed to Step 17. If not, proceed to Step 18.</font></font></dir>
</dir>
<a NAME="Step17"></a><b><font face="TIMES"><font size=+1>Step 17: Performing
a Point-in-Time Restore</font></font></b>
<p><font face="TIMES"><font size=-1>In order to do a point-in-time restore,
you need to do a cold restore of the entire database. (Details on how to
do that are in Step 6.)</font></font>
<p><font face="TIMES"><font size=-1>If you are using <i>ontape</i>, you
will need to apply all logical logs until you reach the one during which
the user/DBA error occurred. Do not apply that logical log.</font></font>
<p><font face="TIMES"><font size=-1>If you are using <i>onbar</i>, you
can use the <i>-n xxx </i>or <i>-t time </i>features of <i>onbar -r</i>
to recover up to a point in time just prior to the user/DBA error.</font></font>
<dir>
<dir><font face="TIMES"><font size=-1>Once you have done this, proceed
to Step 19.</font></font></dir>
</dir>
<a NAME="Step18"></a><b><font face="TIMES"><font size=+1>Step 18: Is Everything
OK?</font></font></b>
<dir>
<dir><font face="TIMES"><font size=-1>If you saw any of the flags mentioned
in Step 15, return to Step 8. If not, proceed to Step 19.</font></font></dir>
</dir>
<a NAME="Step19"></a><b><font face="TIMES"><font size=+1>Step 19: Making
a Backup</font></font></b>
<p><font face="TIMES"><font size=-1>Every restore should be followed immediately
by a full backup. Of course, Informix allows you do so online. Don’t consider
the restore finished until you have completed this backup.</font></font>
</body>
</html>