Hello Lin and Hello Marty and whoever monitors this discussion,

from support perspective when I observe this discussion, I hope all
goes well, that these things don't raise more problem later than it
solves currently.

I'm convinced what you try to achieve is for your business needs.
This is fact: you need it.

I was thinking rather incarnation project for finddbs, but:
I've been told in last Code Sprint there were some discussion around
this topic and Henrik would have some scripts doing the things better,
which were used for Tru64 platform.
Unfortunately I was not there neither I have any other detail on hand.

Best thing would be to start with the scripts and see whatelse needs to
be done.
Once done, we can consider putting them to into ingres/sig/...
directory so every one could take advantage.
This would allow us (customers and Actian engineers) operating on "safe
water".

Thanks - Bilgihan
PS: I'll send the same info to Henrik shortly


--
bilgihan

Hi Bilgihan,

The more I think about this the more I think the best thing would be to remove all the hard-coded paths completely from the database config files and from the journals and dumps. I have a gut feeling we could rely on the location names to do what we need. This would make recovery in a DR box with different paths real easy, we would just need to ensure the same location names exist. It would remove any need to do editing on these critical files.

Marty

-----Original Message-----
From: Ingres Forums [mailto:info-ingres (AT) kettleriverconsulting (DOT) com]
Sent: 01 December 2011 13:33
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: Re: [Info-Ingres] Editing a configuration file


Hello Lin and Hello Marty and whoever monitors this discussion,

from support perspective when I observe this discussion, I hope all
goes well, that these things don't raise more problem later than it
solves currently.

I'm convinced what you try to achieve is for your business needs.
This is fact: you need it.

I was thinking rather incarnation project for finddbs, but:
I've been told in last Code Sprint there were some discussion around
this topic and Henrik would have some scripts doing the things better,
which were used for Tru64 platform.
Unfortunately I was not there neither I have any other detail on hand.

Best thing would be to start with the scripts and see whatelse needs to
be done.
Once done, we can consider putting them to into ingres/sig/...
directory so every one could take advantage.
This would allow us (customers and Actian engineers) operating on "safe
water".

Thanks - Bilgihan
PS: I'll send the same info to Henrik shortly


--
bilgihan


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

Sounds like something we could have done with a long time ago.

We have always used this method for taking copies of production into test
or dev, not DR so we never needed to rollforward the journals .
We use it for changing paths, database names - and even the dbid.
However, the limitations are that we can only use as many characters as
are in use already .
So all the paths etc have to be the same length afterwards as they were
before.

More flexibility is the key.

Regards,
Lin



Internet
martin.bowes (AT) ctsu (DOT) ox.ac.uk
Sent by: info-ingres-bounces (AT) kettleriver...ting (DOT) com
02/12/2011 08:27
Please respond to
info-ingres (AT) kettleriverconsulting (DOT) com


To
info-ingres (AT) kettleriverconsulting (DOT) com
cc

Subject
Re: [Info-Ingres] Editing a configuration file






Hi Bilgihan,

The more I think about this the more I think the best thing would be to
remove all the hard-coded paths completely from the database config files
and from the journals and dumps. I have a gut feeling we could rely on the
location names to do what we need. This would make recovery in a DR box
with different paths real easy, we would just need to ensure the same
location names exist. It would remove any need to do editing on these
critical files.

Marty

-----Original Message-----
From: Ingres Forums [mailto:info-ingres (AT) kettleriverconsulting (DOT) com]
Sent: 01 December 2011 13:33
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: Re: [Info-Ingres] Editing a configuration file


Hello Lin and Hello Marty and whoever monitors this discussion,

from support perspective when I observe this discussion, I hope all
goes well, that these things don't raise more problem later than it
solves currently.

I'm convinced what you try to achieve is for your business needs.
This is fact: you need it.

I was thinking rather incarnation project for finddbs, but:
I've been told in last Code Sprint there were some discussion around
this topic and Henrik would have some scripts doing the things better,
which were used for Tru64 platform.
Unfortunately I was not there neither I have any other detail on hand.

Best thing would be to start with the scripts and see whatelse needs to
be done.
Once done, we can consider putting them to into ingres/sig/...
directory so every one could take advantage.
This would allow us (customers and Actian engineers) operating on "safe
water".

Thanks - Bilgihan
PS: I'll send the same info to Henrik shortly


--
bilgihan
------------------------------------------------------------------------
bilgihan's Profile:
http://community.actian.com/forum/me...hp?userid=8658
View this thread: http://community.actian.com/forum/sh...ad.php?t=14087

_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres


__________________________________________________ _________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited.

Please refer to http://www.bnpparibas.co.uk/en/infor...de=ECAS-845C5H for additional disclosures.

At the Codesprint in June 2011 as Bilgihan mentions I was working on porting
Our Company's "job" to do this work - then renamed to "relocateckp" into the Sig-directory.

The job is based upon some Shell-scripts and one C-program (which makes the changes in the CNF-file),
And makes it possible for us to load a database on another machine, with another installationcode
And the database under a different name.

One essential job for making database-copies on other machines for Slave-backups for different purposes
Also in the migration process where you need to have the time and possibility to unload a database to
Reload on another machine.type (although it should be possible to use "relocateckp" as well for most platforms,
As long as the Character-sets is identical).

By the way just remember to take partions off while creating the Unload/Reload-scripts with Unloaddb to avoid
Using the Logfile during Reload.

At the time of the Codesprint we were in the early face of our migration from TRU64 (AXP.OSF) towards
Linux, so didn't get it all to work during the Codesprint, and been quite busy since at work.

Al though our C-program was re-niced and our extract of the Ingres-include files replaced with the correct
Ingres-include files, and building set up the Ingres-way, lots of translation, replacing and removing internal stuff.

The work at that time has been parked in a Tar-archieve (on several hands) but not secretly hidden inside the Source-code :-).

Our present Linux-version of the Shell-scripts has now been given back to Ingres Support (with lots of Danish and Internal setups inside :-).

Kind regards
Henrik Georg Sørensen
Seniorconsultant, Ingres Database Administrator for Decades
Organisator - En del af KMD
-----Oprindelig meddelelse-----
Fra: info-ingres-bounces (AT) kettleriver...ting (DOT) com [mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] På vegne af Martin Bowes
Sendt: 2. december 2011 09:45
Til: Ingres and related product discussion forum
Emne: Re: [Info-Ingres] Editing a configuration file

Hi Bilgihan,

The more I think about this the more I think the best thing would be to remove all the hard-coded paths completely from the database config files and from the journals and dumps. I have a gut feeling we could rely on the location names to do what we need. This would make recovery in a DR box with different paths real easy, we would just need to ensure the same location names exist. It would remove any need to do editing on these critical files.

Marty

-----Original Message-----
From: Ingres Forums [mailto:info-ingres (AT) kettleriverconsulting (DOT) com]
Sent: 01 December 2011 13:33
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: Re: [Info-Ingres] Editing a configuration file


Hello Lin and Hello Marty and whoever monitors this discussion,

from support perspective when I observe this discussion, I hope all
goes well, that these things don't raise more problem later than it
solves currently.

I'm convinced what you try to achieve is for your business needs.
This is fact: you need it.

I was thinking rather incarnation project for finddbs, but:
I've been told in last Code Sprint there were some discussion around
this topic and Henrik would have some scripts doing the things better,
which were used for Tru64 platform.
Unfortunately I was not there neither I have any other detail on hand.

Best thing would be to start with the scripts and see whatelse needs to
be done.
Once done, we can consider putting them to into ingres/sig/...
directory so every one could take advantage.
This would allow us (customers and Actian engineers) operating on "safe
water".

Thanks - Bilgihan
PS: I'll send the same info to Henrik shortly


--
bilgihan


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres


_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

Martin Bowes wrote:

Hear hear.

--
Roy

UK Ingres User Association Conference 2012 will be on Tuesday June 19 2012.
The latest information is available from www.uk-iua.org.uk.

On Dec 2, 2011, at 3:27 AM, Martin Bowes wrote:

Indeed.

The only reason (as far as I know) that it hasn't been done already is that
recovery can get tricky. Offline crash recovery sort-of-kind-of tries to use
as little context as possible, specifically including location knowledge and
location availability. Digging through recovery to see what can and
should be done takes the project from "maybe a week or so" up to
"maybe three weeks, a month, who knows", which is why it hasn't
been done already in stealth mode.

I completely agree, though. Storing an absolute path anywhere outside of
the location definition itself is wrong, broken, and evil.

Karl

So here is the latest position....

Having fixed a few bugs in my configuration file editor...

Realising that I just can't edit the hard-coded paths stored in the journal by a sysmod I decided to play with a recovery where a sysmod had not been performed on the test database.

So I created a journaled table in a database, inserted some initial data, did a backup, and then updated the table and exited the database. Using auditdb I confirmed the update was in the journals.

I transferred the journals etc to the DRH.

I edit the paths in the config and saved config files and do a recovery.

The recovery completes successfully...or at least claiming success.

The table with the initial data has been recovered, but the journalled updates have not been recovered.

Examining the recovery log I find that the recovery stopped at a transaction with LSN 4CE13251,0B20E2BE. Examining the audit trail on the source host we see that the updates start with a transaction LSN 4CE13251,0B20E2C3.

The audit trail on the DRH also refuses to display the updates. Yet the journal files on source and DRH are identical.

Ideas please.

FYI. The clock on the DRH is about 4minutes ahead of the clock on the source host.

Marty


-----Original Message-----
From: Karl Schendel [mailto:schendel (AT) kbcomputer (DOT) com]
Sent: 02 December 2011 14:35
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] Editing a configuration file


On Dec 2, 2011, at 3:27 AM, Martin Bowes wrote:

Indeed.

The only reason (as far as I know) that it hasn't been done already is that
recovery can get tricky. Offline crash recovery sort-of-kind-of tries to use
as little context as possible, specifically including location knowledge and
location availability. Digging through recovery to see what can and
should be done takes the project from "maybe a week or so" up to
"maybe three weeks, a month, who knows", which is why it hasn't
been done already in stealth mode.

I completely agree, though. Storing an absolute path anywhere outside of
the location definition itself is wrong, broken, and evil.

Karl



_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres