I've been following the debate on whether or not rollforwarddb should check
that the database name matches the database name in the configuration file
before proceeding.

FWIW, rollforwarddb is usually quite picky about when it runs, so if the
config file is fundamentally wrong it should not carry on like the Light
Brigade! CA should be kind enough make a change in the form of a bug fix
IMO.

If enough people make a big enough noise, things will happen.

Here's one example of an SQL bug that CA initially said needed to be an
"enhancement", but decided to fix after I stood my ground! :-


create table test as select * from iitables where 1=2;

insert into test
select * from iitables where table_owner = '$ingres'
union
select * from iitables where table_owner != '$ingres';

Rollback;

NOTE: You should not be seeing E_US09C7

************************************************** **********************
DISCLAIMER
The information contained in this e-mail is confidential and is intended
for the recipient only.
If you have received it in error, please notify us immediately by reply
e-mail and then delete it from your system. Please do not copy it or
use it for any other purposes, or disclose the content of the e-mail
to any other person or store or copy the information in any medium.
The views contained in this e-mail are those of the author and not
necessarily those of Admenta UK Group.
************************************************** **********************

I'm only speaking for myself and NOT CA when I say the following -

There is obviously a judgement call in some cases whether something is
a bug or not. However in this case the bug only occurs if you do
something unsupported, something that's not necessary for
rollforwarddb to work *and* then make a mistake whilst doing it. The
question is how far do we go in trying to anticipate and check for
such things, bearing in mind that any time taken to fix this is taken
away from fixing other problems?

It's not a bad thing to have extra checking - and if Karl's right
possibly not that hard to do - but this is a problem that can easily
be avoided so I don't think it's unreasonable to ask someone to wait
for an enhancement - since it's already possible to do what they need
to do without resorting to unsupported methods.

Also - if the real problem is timely response to enhancement requests
then let's look at that process not classify everything as a bug.
There is a procedure for escalating business critical enhancements.
And of course these days one can take the source and fix it oneself.

BTW I mean no disrepect to Jonathan - I've been in similar situations
myself. My horror story is of a production system that was down for
the best part of 3 days because of my cnf-file hacking. That's one of
the reasons I'm so against manipulating cnf files and very much for
enhancements that provide supported ways to acheive the same ends
where they don't exist already.

Richard's INSERT bug below is an interesting case. The documentation
for INSERT syntax says you can have a subselect - but a subselect does
not include a UNION. The decision to fix this was because

a) it's inconsistent with CREATE TABLE ... AS which also specifies a
subselect but allows UNIONs
b) the fix was a one-liner

which gives some clue as to the judgement calls that get made.

Anyway, as I said, this is very much my own opinion.


On Thu, 20 Jan 2005 10:26:59 -0000, David Richard
<Richard.David (AT) aah (DOT) co.uk> wrote:
--
Paul Mason

Thanks for the reply Paul and to all the others who have replied. I can
see both sides of the argument here and agree with both of them. Yes,
it's not a bug in the true sense and yes it would be nice if a sanity
check was done, thus tightening the noose somewhat. There's always the
chance someone could maliciously move the config files and the proposed
change would prevent any harm from occurring. I also liked the
suggestion of a source and destination option for the rollforwarddb but
I guess that's quite a bit more work but could benefit a lot of people.

To clarify things a little. We were effectively if a full disaster
recovery situation as the server was being completely rebuilt from
scratch with new disks. Having restored the ckp, jnl and dump locations
from tape, we were under the impression that it was "good practice" to
then copy the config file from dmp to data prior to restoring the
databases (NOTE we don't recover the data files, just the directories to
save a little time, although the data files are backed up to tape as a
last ditch safety measure). In this scenario, do we need to copy the
dmp config file to data or will the rollforwarddb handle everything ok?


At the end of the day though, a careful check of the output from infodb
imadb might have pointed to the fact that it thought it was looking at
the live db. The whole in my foot is slowly healing, the barrage from
the IT Director has dwindled to the occasional mortar attack and the
Alps are laden with snow just in time for this weekend ;-) I'm sure
after a few Gluvine's and a couple of trips to the half pipe, I'll have
completely forgotten about this ...

Cheers and thanks for the help as usual

Jon

-----Original Message-----
From: info-ingres-admin (AT) cariboulake (DOT) com
[mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of Paul Mason
Sent: 20 January 2005 12:19
To: info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] Bug or feature? [was Rollforwarddb disaster]


I'm only speaking for myself and NOT CA when I say the following -

There is obviously a judgement call in some cases whether something is
a bug or not. However in this case the bug only occurs if you do
something unsupported, something that's not necessary for
rollforwarddb to work *and* then make a mistake whilst doing it. The
question is how far do we go in trying to anticipate and check for
such things, bearing in mind that any time taken to fix this is taken
away from fixing other problems?

It's not a bad thing to have extra checking - and if Karl's right
possibly not that hard to do - but this is a problem that can easily
be avoided so I don't think it's unreasonable to ask someone to wait
for an enhancement - since it's already possible to do what they need
to do without resorting to unsupported methods.

Also - if the real problem is timely response to enhancement requests
then let's look at that process not classify everything as a bug.
There is a procedure for escalating business critical enhancements.
And of course these days one can take the source and fix it oneself.

BTW I mean no disrepect to Jonathan - I've been in similar situations
myself. My horror story is of a production system that was down for
the best part of 3 days because of my cnf-file hacking. That's one of
the reasons I'm so against manipulating cnf files and very much for
enhancements that provide supported ways to acheive the same ends
where they don't exist already.

Richard's INSERT bug below is an interesting case. The documentation
for INSERT syntax says you can have a subselect - but a subselect does
not include a UNION. The decision to fix this was because

a) it's inconsistent with CREATE TABLE ... AS which also specifies a
subselect but allows UNIONs
b) the fix was a one-liner

which gives some clue as to the judgement calls that get made.

Anyway, as I said, this is very much my own opinion.


On Thu, 20 Jan 2005 10:26:59 -0000, David Richard
<Richard.David (AT) aah (DOT) co.uk> wrote:
--
Paul Mason
_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

__________________________________________________ ___________________
This message has been checked for all known viruses by bluesource. For
further information visit www.blue-source.com

powered by Messagelabs


<font size='1' face='arial'>************************************* *********************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. No one else is authorised to distribute, forward,
print, copy or act upon any information contained in this email.
If you have received this email in error, please notify the sender.

Hiscox Syndicates Limited, Hiscox Insurance Company Limited,
Hiscox Connect Limited, Hiscox Underwriting Limited and
Hiscox Investment Management Limited are authorised and
regulated by the Financial Services Authority. Hiscox plc is a
company registered in England and Wales under company
registration number 2837811 and registered office at
1 Great St Helen's, London EC3A 6HX
************************************************** ********************


__________________________________________________ ___________________
This message has been checked for all known viruses by blue-source. For further information visit www.blue-source.com

powered by Messagelabs

At 12:57 PM +0000 1/20/05, Gibson Jonathan wrote:
An interesting idea, one that definitely would have to go into the DAR
queue. (I.e. it's not a 5 minute fix!).

Personally, I'd like to see a couple other config-file related
enhancements:
- rename database
- given a database data and dump area, fix the config file paths to
match the location names. Alternatively, eliminate full paths from the
config file. (This one is for cross-installation snapshotting; and,
as a system administrator, getting rid of the full path strings has been
on my list for many years.)
- rollforwarddb -the_data_files_are_there_just_apply_the_dumps_plea se

I have little programs that do the first two (private, crappy, unsupported,
notwork on 2.6 or later, don't ask me for a copy, etc etc), and with
great effort one can fake the third. I'd love to see them done right,
though, with proper error checking, decent command syntax, etc. Again,
none of this is 5-minute-or-less.

If there's no data directory copy of the config file, rollforwarddb will
automatically look at the dmp directory.

Karl

ikugan26;27665 Wrote:
The first thing I would do is to get Service Pack 6 for 2.6 - 2.6/0803
- which assuming you have a support agreement, can be downloaded from
esd.ingres.com. If the error persists, then raise an issue with support.


--
denjo02