Switching to next AI segment manually under OE replication

[pinne65]

Hello,

We are running OE replication between a production server and a backup server. Currently the AI files are of fixed size and fairly large 500 MB ~ 4-6 hours of business.

On a regular basis a script archives full extents to a backup SAN.

We'd like to change the script and force extent switches at fixed shorter intervals instead. This in order to be able to restore to a fixed point in time just before accident X occurred and got replicated.

I did a test and issued "aimage new to the database. But it seems like it somehow broke OE replication. The database did indeed start using the next extent. But the old one remained locked. And the transfer of transactions between the databases came to a halt (verified w dsrutil). Replication didn't pick up again until I restarted the databases.


I'd like to give it a go again but thought I'd ask around first just in case. I can't see anything that says I can't do this or am I completely missing something here?



On a side note; We have a lot of extents, enough to cover a week of downed OE replication. I'm toying with the thought of replacing them with fewer variable ones. But we also have a lot of disk space and I kinda of like the thought of having that much space reserved for database usage. And I've also heard of, but never seen, performance degredation by using variable AI extents.


Any1s 5 cents

TIA

/Pinne

10.2B03 Enterprise on RHEL 5.4

 

[TomBascom]

You can roll forward to a point in time. It's part of the rfutil syntax. It doesn't matter if the archived ai extent is fixed or variable. But IMHO it is much easier to work with variable extents.

You will only see a performance impact under *very* heavy load -- basically you have to be running a benchmark. Most normal operations will never notice the difference.

With variable extents you would still want to have the disk space reserved for the same reason -- you just wouldn't be consuming it unless it is actually holding some data. I guess that might be harder to get a bean counter to understand?

Did you run aimage new on the source db? That should be a perfectly ok thing to do. How large is your -pica value? Are you using the ai management daemon or are you doing scripted after-imaging?

 

[Rob Fitzpatrick]

If you want fixed-interval extent switches, using the AI File Management Daemon would make your life easier. It's one less thing for which to develop and test robust script logic.

Also, later service packs of 10.2B contain numerous fixes for OE Replication. You should look at installing SP07.

 

[pinne65]

Yup, aimage new on the source and to clarify; that was the only database I had to restart in order to get replication going again.

We have a shell script that loops:

1. gets the name for the first full ai extent (_rfutil theDB -C aimage extent full)
2. gets the sequence# (_rfutil theDB -C aimage query SEQUENCE by NAME nameFromStep1)
3. copies the full extent to a safe place (cp nameFromStep1 /safePlace/theDb.ai.seqNumFromStep2)
4. marks the full extent empty (_rfutil theDB -C aimage extent empty nameFromStep1)

until no more full names are retrived.


-pica is 256 (K). Too small to allow for aimage new under full load in production? Though at the time I did the test there was no user or batch activity on the system.... Since we are basically swimming in memory, should I just crank it up to the MAX 8MB?


Our application provider does all the Progress updates...

 

[Rob Fitzpatrick]

You should use the max (8192) for -pica.

What about hardware specs and DB startup parameters and BI settings on the replication target? If the specs on the target side don't measure up to the source then it can become a bottleneck and eventually cause performance issues in production.

 

[pinne65]

Thanks, I'll crank the -pica to the max!

Will that improve performance or will it just prevent what shouldn't happen from happening ;-)


The target is nowhere near the source in hardware right now. But it's basically idle at the moment with just the replication going. It's a vm, and yes, we would have to restart it in order to give it more memory & cpu. But without any users on the system that should just be a matter of minutes, which has been deemed acceptable.

BI settings, cluster & log sizes are the same on both servers.

 

[TomBascom]

Actually the max for -pica was punched up to something like 1,000,000 in one of the recent service packs.

We have a shell script that loops:

1. gets the name for the first full ai extent (_rfutil theDB -C aimage extent full)
2. gets the sequence# (_rfutil theDB -C aimage query SEQUENCE by NAME nameFromStep1)
3. copies the full extent to a safe place (cp nameFromStep1 /safePlace/theDb.ai.seqNumFromStep2)
4. marks the full extent empty (_rfutil theDB -C aimage extent empty nameFromStep1)

until no more full names are retrived.

I cannot see why "aimage new" should cause a problem. It sounds like a bug to me. Is it a repeatable problem?

Our application provider does all the Progress updates...

Sounds like a recipe for disaster.

 

[Rob Fitzpatrick]

The -pica limit was bumped up from 8192 to 1,000,000, but only in 11.2; not in 10.2B.

I agree with Tom, your AP is keeping you from getting bug fixes you need. There shouldn't be any technical reason why you can't run at least 10.2B07. Push them for it.

 

[pinne65]

Thanks again for your information and help Tom & Rob!

I'll try another aimage new this weekend and see if it happens again. Last weekend was the first time I tried it

And I'll get on our AP about an update.

 

[pinne65]

Ok,

I tried aimage new again and this time the extent didn't remain locked. But I think I might have misinterpreted the situation the first time around.

The night before I ran aimage new, an online full backup runs which of course also runs aimage new.

When I listed the ai extents, the previous one remained locked for quite a while and the target dsrutil listed "current as of" with the previous night's backup date. This threw me off a little and I semi panicked the first time.

Thinking of it I realized that nothing new had happened since the night before. I entered a transaction and - dsrutil changed "current as of " to immediately after that, and the previously locked extent changed status to full.