Hello guys,
I desperately need your HELP!
Case 1
It's about CDC. A quick overview:
Source: Installed on Solaris (latest patches applied as recommended by IBM)
Target: Installed on hp-ux (latest patches applied)
TS: Installed on Red Hat Server (also latest patches applied
TS Client: On Windows XP with latest patches as well.
Source and Target have both Oracle 10g DB. We are trying to (obviously) replicate some tables. Things were going find, till I came one morning to find some deamon errors from source. Tried to investigate and check traces with no help. The error gives you many possibilities, but they are all about archive log, wrong SCN, not enough space, blah blah.. (If you faced it, then you know what I mean).
I've checked the source, and there is no archive log been moved (though there is automated RMAN script). I checked using ./dmshowlogdependency and made sure that the given log is there.
IBM support wasn't helping me best, till they arranged a conference call with some expert. We talked, and he suggested after I told him the whole scenario that there might be an uncommited transaction since too long that is attached to a certain old redo log, etc.. I checked, and yes there was one uncommited transaction since more than 3 months (the db have high transactions rate by the way). fixed that transaction, and replication got back to working (though we had to refresh from the beginning, then mirror).
Two days, replication running smoothly, came back after the weekend to find the same error took place at 2am Friday. I went crazy, checked for uncommited transactions but got none, checked redo log and everything was there and since I'm just clueless!
Case 2:
Same error as above, except that the source now is the hp-ux with CDC Oracle and target is Red Hat with CDC for DataStage. We use Flat file replication through CDC and use them inside DataStage. All was good, till brilliant me decided to clean some old redo logs, and I did, after that the same issue as I mentioned above is showing up. I can't recover them since they are rubbish and I actually deleted them (were for development purposes). ./dmsetbookmark is not working, making new subscription is not working (same issue show up), even if I made new CDC DS instance same issue. Didn't try making new CDC Oracle instance, since other subscriptions are dependent on that one.
How can life be good again? Please give me ALL YOU GOT!!
Thank you.
IBM Change Data Capture for Oracle (redo log)
Moderators: chulett, rschirm, roy
What version of CDC are you running? (6.3 or 6.5) The dmshowlogdependency command needs to be run on each subscription because the bookmarks are set on each subscription. It sounds like you might have multiple subscriptions and the 2:00 AM Friday failure just points you to the source. You need to check the log dependency on every subscription.
I don't really know what could be happening in Case 2, but after you deleted the subscription, did you close and re-open Management Console? Anytime I delete a subscription or mapping, I close and re-open Managment Console to clear out the cache as it seems to "remember" previous subscription and mapping names and won't let me recreate them.
Have you seen this documentation?
http://www-01.ibm.com/support/docview.w ... wg27018447
You may have IOT's or other unsupported table types in your subscriptions that could be compounding the issues.
I don't really know what could be happening in Case 2, but after you deleted the subscription, did you close and re-open Management Console? Anytime I delete a subscription or mapping, I close and re-open Managment Console to clear out the cache as it seems to "remember" previous subscription and mapping names and won't let me recreate them.
Have you seen this documentation?
http://www-01.ibm.com/support/docview.w ... wg27018447
You may have IOT's or other unsupported table types in your subscriptions that could be compounding the issues.
Hi,
Thanks for your reply and excuse my delay in response due to 90345 jobs I have at the moment
Well, for case 1 the version is 6.3 with the latest 25 something patch.
There is only one subscription which is dependent the source agent. Target is being used as target (obviously) as well as source for some other internal subscription. Any other idea? What do you mean by unsupported table types? How can I make sure of that? As I've mentioned before, it works find for a period, could be days, then out of the sudden it fails.
For case 2, the solution was the one you given for case 1. I had some other subscriptions which were depending on the redo log (temp actually), deleted them and life's good again.
I'd appreciate any help for the first issue, as this case is getting on my nerves. I could simply change to refresh then mirror again (start all over), but then I'll never know the cause of the issue nor how to fix if I face it in the future (since this is the 3rd this happens).
Thank you.
Thanks for your reply and excuse my delay in response due to 90345 jobs I have at the moment
Well, for case 1 the version is 6.3 with the latest 25 something patch.
There is only one subscription which is dependent the source agent. Target is being used as target (obviously) as well as source for some other internal subscription. Any other idea? What do you mean by unsupported table types? How can I make sure of that? As I've mentioned before, it works find for a period, could be days, then out of the sudden it fails.
For case 2, the solution was the one you given for case 1. I had some other subscriptions which were depending on the redo log (temp actually), deleted them and life's good again.
I'd appreciate any help for the first issue, as this case is getting on my nerves. I could simply change to refresh then mirror again (start all over), but then I'll never know the cause of the issue nor how to fix if I face it in the future (since this is the 3rd this happens).
Thank you.
From page 54 of the above documentation, these table types are UNSUPPORTED on Oracle:
- Compressed
- Indexed Organized Table(IOT)
- Clustered
You need to perform full table refreshes instead of mirroring on these table types. You can find your table type attributes with this query:
select TABLE_NAME, PARTITIONED, IOT_TYPE, CLUSTER_OWNER, COMPRESSION from DBA_TABLES
where TABLE_NAME like '%my_table_name%';
Are you sure CDC is looking in the correct archive log destination? This is configured with the dmconfigurets command. It could be that CDC is just reading the current redo logs and keeping up with current activity on the source, but when CDC falls behind and the log is achived then CDC is looking in the wrong directory. Just a thought...
- Compressed
- Indexed Organized Table(IOT)
- Clustered
You need to perform full table refreshes instead of mirroring on these table types. You can find your table type attributes with this query:
select TABLE_NAME, PARTITIONED, IOT_TYPE, CLUSTER_OWNER, COMPRESSION from DBA_TABLES
where TABLE_NAME like '%my_table_name%';
Are you sure CDC is looking in the correct archive log destination? This is configured with the dmconfigurets command. It could be that CDC is just reading the current redo logs and keeping up with current activity on the source, but when CDC falls behind and the log is achived then CDC is looking in the wrong directory. Just a thought...
Hi again,
None of the tables is compressed, IOT or clustered.
For the second though, I believe CDC is looking in the correct directory. But how can this be configured through dmconfigurets? I thought CDC looks for oracle configuration file to get those destinations.. Any comment on this one?
Another thing, the source environment is oracle clustered, and I believe there is certain configuration, but that's for fail over, and as far as I know, there has never been a fail over (yet).
Please more thoughts and ideas.. Highly appreciated.
None of the tables is compressed, IOT or clustered.
For the second though, I believe CDC is looking in the correct directory. But how can this be configured through dmconfigurets? I thought CDC looks for oracle configuration file to get those destinations.. Any comment on this one?
Another thing, the source environment is oracle clustered, and I believe there is certain configuration, but that's for fail over, and as far as I know, there has never been a fail over (yet).
Please more thoughts and ideas.. Highly appreciated.
Sorry, my mistake. As long as you have the ORACLE_HOME path set correctly, CDC should find the archive log directory.
We don't use Oracle RAC or ASM, but that could be the cause of the issues. According to the page 32 of the documentation:
We don't use Oracle RAC or ASM, but that could be the cause of the issues. According to the page 32 of the documentation:
To integrate InfoSphere CDC into your RAC environment, you must first define an
Oracle service for the RAC environment in the tnsnames.ora file and then select
this service when creating an instance of InfoSphere CDC for your RAC
environment in the configuration tool. You must also create a failover script that
automates several InfoSphere CDC commands.