cancel
Showing results for 
Search instead for 
Did you mean: 

Shadow databases, redo and index

Former Member
0 Kudos

We're building a shadow database of our BW system using log shipping. During the recover process I see in Knlmsg the following information:

Thread   0x1C Task     94  2010-05-26 15:09:02
Index          6:  Mark index as not accessible,
REASON=no redo of index creation,ROOT=87357163,FILENO=00000000003317F8
DESCRIPTION:
The index with FileID '00000000003317F8' respectively root '87357163' 
has been disabled due to technical reasons. This is not an error case 
which needs further analizing.
Drop the index and recreate it again.

Does that mean we would have to parse through Knlmsg, find the root page, do a select and recreate this index manually?

Markus

Accepted Solutions (1)

Accepted Solutions (1)

lbreddemann
Active Contributor
0 Kudos

>

> We're building a shadow database of our BW system using log shipping. During the recover process I see in Knlmsg the following information:

> Does that mean we would have to parse through Knlmsg, find the root page, do a select and recreate this index manually?

Hi Markus,

no, you shouldn't need to do that.

Setting the db parameter UseAutomaticBadIndexRecreation (starting with 7.7) the database will take care of this during the startup of the instance when the standby DB is brought online.

Like the Oracle feature NOLOGGING, MaxDB does not log all changes to indexes to the redo log stream.

Therefore it's required to rebuild those indexes that only exist as catalog entries after the recovery process.

If you now say: "Wait a minute! I want my BW standby DB up and running including all indexes as fast as possible - that's why I use a standby DB in the first place...." then you're completely right.

At this point the standby scenario fails, as the indexes need to be recreated.

Unfortunately there is no option in MaxDB to avoid this (unlike Oracle where you can set a FORCE_LOGGING setting).

Now you're not happier (I guess) but at least you got an answer - isn't that something?

regards,

Lars

markus_doehr2
Active Contributor
0 Kudos

> If you now say: "Wait a minute! I want my BW standby DB up and running including all indexes as fast as possible - that's why I use a standby DB in the first place...." then you're completely right.

> At this point the standby scenario fails, as the indexes need to be recreated.

> Unfortunately there is no option in MaxDB to avoid this (unlike Oracle where you can set a FORCE_LOGGING setting).

sigh

So basically this makes the use of a BW shadow system seriously questionable because if that system runs for half a year (or more) and is the started the it will take LOTS of time to create all those indexes, especially since they are created serially.

I've to think about that and discuss...

Thank you for the input!

Markus

lbreddemann
Active Contributor
0 Kudos

HI Markus,

I'd been thinking about this again.

I agree - the "standby-db feature" that comes with MaxDB is a piece of cr*p.

No automatic switchover, no automatic log shipping...

Anyhow.

One option to have something like a standby db also for BW systems would be to use incremental backups instead of log backups.

Actually, for BW systems I'm not too sure whether this wouldn't be the better alternative anyway.

If you think about it.

Take a incremental backup every hour - maybe just via pipe to the target db.

And in case of a failover, the worst case is to recover the missing hour of logs.

What do you think about that?

regards,

Lars

markus_doehr2
Active Contributor
0 Kudos

> I agree - the "standby-db feature" that comes with MaxDB is a piece of cr*p.

> No automatic switchover, no automatic log shipping...

We wouldn't want an automatic switchover and the log shipping can be nicely scripted with error handling and alert mails to Blackberry etc. - this is not the main issue.

> If you think about it.

> Take a incremental backup every hour - maybe just via pipe to the target db.

That's an interesting option, yes. Thank you for that idea!

I just found out that we have another, much more serious 'problem' with a shadow database.

We use BWA and once we switch the database we can't make 100 % sure that

a) all the data is in sync (it should be)

b) we redirect the BWA to the new location automatically

Since TREX is, to be diplomatic, not really easily scriptable (I'm not a python guru, honestly, I hate python), together with IP changes and virt. hostnames and the connector portal (BI-Java) etc. this will effectively prevent us from using a shadow database for BW as we wanted, the whole environment would become too complex to handle.

And btw: it was possible to import archive logs generated on 7.6 into a 7.7 database

Markus

lbreddemann
Active Contributor
0 Kudos

hmm... seems like the last posts are gone right now...

Anybody "moderated" something here?

regards,

Lars

UPDATE:

Now the posts are back ...!?

Quite strange effect!

Edited by: Lars Breddemann on Jun 7, 2010 9:55 PM

UPDATE 2:

Now I got a server error:

> Parent key 9179279 not found when adding child 9181846.

> Details:

> No details available

when I tried to post a reply to this thread...

Edited by: Lars Breddemann on Jun 7, 2010 10:01 PM

lbreddemann
Active Contributor
0 Kudos

> > Take a incremental backup every hour - maybe just via pipe to the target db.

>

> That's an interesting option, yes. Thank you for that idea!

You're welcome!

> I just found out that we have another, much more serious 'problem' with a shadow database.

>

> We use BWA and once we switch the database we can't make 100 % sure that

>

> a) all the data is in sync (it should be)

> b) we redirect the BWA to the new location automatically

>

> Since TREX is, to be diplomatic, not really easily scriptable (I'm not a python guru, honestly, I hate python), together with IP changes and virt. hostnames and the connector portal (BI-Java) etc. this will effectively prevent us from using a shadow database for BW as we wanted, the whole environment would become too complex to handle.

>

Ok, to be honest: I've only a rough idea about BWA and TREX.

As far as I now, TREX indexes are filesystem located - so I don't know whether a db standby could facilitate a TWA standby.

Concerning your remarks to the "redirection" : that was part of what I meant with "automatic switch".

In my opinion a standby database should be as transparent as possible.

If it's necessary to manually change connection parameters on client side, then the standby advantage (quick fail over) is pretty much gone.

> And btw: it was possible to import archive logs generated on 7.6 into a 7.7 database

Well this is how it is designed to be.

If the database accepts logs from an older version, then this is 'by accident'.

regards,

Lars

lbreddemann
Active Contributor
0 Kudos

> > Take a incremental backup every hour - maybe just via pipe to the target db.

>

> That's an interesting option, yes. Thank you for that idea!

You're welcome!

> I just found out that we have another, much more serious 'problem' with a shadow database.

>

> We use BWA and once we switch the database we can't make 100 % sure that

>

> a) all the data is in sync (it should be)

> b) we redirect the BWA to the new location automatically

>

> Since TREX is, to be diplomatic, not really easily scriptable (I'm not a python guru, honestly, I hate python), together with IP changes and virt. hostnames and the connector portal (BI-Java) etc. this will effectively prevent us from using a shadow database for BW as we wanted, the whole environment would become too complex to handle.

>

Ok, to be honest: I've only a rough idea about BWA and TREX.

As far as I now, TREX indexes are filesystem located - so I don't know whether a db standby could facilitate a TWA standby.

Concerning your remarks to the "redirection" : that was part of what I meant with "automatic switch".

In my opinion a standby database should be as transparent as possible.

If it's necessary to manually change connection parameters on client side, then the standby advantage (quick fail over) is pretty much gone.

> And btw: it was possible to import archive logs generated on 7.6 into a 7.7 database

Well this is how it is designed to be.

If the database accepts logs from an older version, then this is 'by accident'.

regards,

Lars

lbreddemann
Active Contributor
0 Kudos

> > Take a incremental backup every hour - maybe just via pipe to the target db.

>

> That's an interesting option, yes. Thank you for that idea!

You're welcome!

> I just found out that we have another, much more serious 'problem' with a shadow database.

>

> We use BWA and once we switch the database we can't make 100 % sure that

>

> a) all the data is in sync (it should be)

> b) we redirect the BWA to the new location automatically

>

> Since TREX is, to be diplomatic, not really easily scriptable (I'm not a python guru, honestly, I hate python), together with IP changes and virt. hostnames and the connector portal (BI-Java) etc. this will effectively prevent us from using a shadow database for BW as we wanted, the whole environment would become too complex to handle.

>

Ok, to be honest: I've only a rough idea about BWA and TREX.

As far as I now, TREX indexes are filesystem located - so I don't know whether a db standby could facilitate a TWA standby.

Concerning your remarks to the "redirection" : that was part of what I meant with "automatic switch".

In my opinion a standby database should be as transparent as possible.

If it's necessary to manually change connection parameters on client side, then the standby advantage (quick fail over) is pretty much gone.

> And btw: it was possible to import archive logs generated on 7.6 into a 7.7 database

Well this is how it is designed to be.

If the database accepts logs from an older version, then this is 'by accident'.

regards,

Lars

Answers (0)