Hi,
that is possible as well. For that I would have a program that
controls the ontape via ontape's prompts.
The problem is, that a "tape" could become full and ontape would
ask for another tape when you don't expect it (e.g. when a lot of BLOB
changes happened and the BLOBs go to the log tape along with the
corresponding log files it can happen that a log tape gets unexpectedly
full).
Whenever ontape asks for a new log tape, the program has to detect
this from ontape's output prompt, then first processes the current "tape"
(i.e. do the file copy/compress/whatever and copy to remote tape), then
reset the file (e.g. truncate to zero length) before answering ontape's
prompt with a RETURN character. Then ontape will write the next tape.
With such a setup you could even use continuous log backup as you
did in the past ...
This is a bit more complicated than the named pipe trick, but still it is
doable.
I would not really rely on the assumption that just calling "ontape -a"
(e.g. from log full script) will surely fit all log data on one tape. You
never
know, how long an "ontape -a" really takes as it would also backup log
files that are filling while "ontape -a" is running. Therefore if in some
not-anticipated scenario (e.g. unscheduled load job, massive delete, ...)
your logs fill faster than "ontape -a" can back them up, such a
mechanism would break.
And probably that's the moment where you would need it most.
Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management
informix-list-bounces@iiug.org wrote on 10.10.2006 14:11:26:
Quote:
Martin Thanks. I understand the concept but need to think through (and test) whether ontape -c would handle this correctly and hold the local tape drive open and positioned, or whether I would have to use ontape -a from a log_full script. Another solution I have thought of is to allow ontape -a to write to my local tape drive through log_full and then immediately manually extract the filled logical log off the disk. Anyone know if this is possible ?? Keith On 10/10/06, Martin Fuerderer <MARTINFU@de.ibm.com> wrote:
Quote:
Hi, not officially. The trick is to create a named pipe and have a program running that reads from that named pipe. In your case it would read and duplicate the data to the local and to the remote tape device. Regarding the implementation of this program you are on your own (clever shell script or small C-programm, ...). Maybe someone within IIUG has solved that problem already for you. In your onconfig file you specify the named pipe as LTAPEDEV. That way "ontape -c" will write the data into the named pipe, so that your program can read the data. You may have to spend some additional thought on the handling of "tapes". As you will still have the LTAPESIZE configured, "ontape -c" will prompt for a new tape every so often. (Currently I'm not sure if the LTAPESIZE=0 is already supported in your version. You may want to check that and possibly give it a try.) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management Informix URLs list: http://home.arcor.de/mfu1/informix/urls.html Informix in the news:
|
|
http://www.crn.com/sections/softwar...cleId=193004835
(to
Quote:
|
a different tape drive) running continuously from a dedicated terminal. The log tape is changed daily at 10:00 and sent off-site with the archive tape. This works for us and prvodes an easily understood and tested
|
restore
Quote:
|
mechanism both to the same machine or off-site. Management have noted that the log tape is on-site and 'vulnerable'
|
to
Quote:
|
fire, flood and articulated lorries (ground floor server room !) whilst it is receiving log files. I have a second server (also AIX) off-site at the end of a wide pipe and would like to ship the log files there as they fill (using any well documented log_full.sh script) however, I want also to retain
|
the
Quote:
|
convenience of having the logs on tape to maintain the existing restore mechanism. Is it possible to archive completed log files to BOTH tape and
|
disk??