How to find count of records based on batch wise.

Question

Hi All,
We are working on OWB10gr2. I would like share one requirement. Any one can suggest me how to do it and which is the best way to get accurate information.
We have 2 schemas’ like nia_src and nia_tgt. currently we are moving data from nia_src to nia_tgt for that reason we implemented some mappings based on requirement. In my source schema (nia_src) having 100 tables with data and similar structure replicated in target schema (nia_tgt).
In source schema every table having one date field for which record is inserted and based on that field we can find how may records are inserted on particular table ,particular time.
Same like target also maintaining date fields for tracking purposes.
We have done some mappings and scheduled also. Every day we are into the target with incremental data. All are working fine not any issues.
I wanted to know how many records inserted, updated, merged for particular batch
How can we find?
Can we find exact information in OWB_REP_OWNER schema on WB_RT_AUDIT?.
For tracking purposes I need to find those values how many records are available in
Source table and how many records are populated to the target schema?
How to find schedule batch count of records table wise for batch wise?
Please suggest me any one on this.
thanks and regards,
venkat.

Answer 1

RE: based on pre operator can we find count of records. if yes how to do it.
No, you cannot tell from the pre- operator how many records will be inserted or updated into a mapping. How could you? The mapping hasn't run yet!
At best (if you have simple mappings with single targets) you could come up with a strategy to have the pre-mapping procedure aware of it's package name, then select from user_source for that package body until you find that first cursor used for the row-based processing, copy the cursor into a local variable, and then execute immediate select count(*) from that cursor definition. But still, all that would get you is the number of rows selected - not inserted / updated / errored etc.
A post-mapping procedure that is aware of the package name will, however, run prior to package exit so that the package spec is still in memory so you can access the public variables in the package spec. We do that in our standard post-mapping procedure
CREATE OR REPLACE procedure erscntrl_finalize_prc(
                       p_process_id     in  number,
                       p_process_name   in  varchar2)
as
      l_numread      number         := 0;
      l_numInserted  number         := 0;
      l_numUpdated   number         := 0;
      l_numMerged    number         := 0;
      l_owb_audit_id number         := 0;
      l_owb_status   number         := 0;
      sqlStmt        varchar2(2000) :=
                           'begin '||
                           '  :1 := '||p_process_name||'.get_selected; '||
                           '  :2 := '||p_process_name||'.get_inserted; '||
                           '  :3 := '||p_process_name||'.get_updated; '||
                           '  :4 := '||p_process_name||'.get_merged; '||
                           '  :5 := '||p_process_name||'.get_audit_id; '||
                           '  :6 := '||p_process_name||'.get_status; '||
                           ' end;';
begin
      -- we use dynamic SQL to return required audit field values.
      --  This allows us to alter which values we need at a later date
      --  without impacting the deployed mappings.
    execute immediate sqlStmt
    using   out l_numread,   out l_numInserted,  out l_numUpdated,
            out l_numMerged, out l_owb_audit_id, out l_owb_status;
  -- then execute our own logging package.
   owb_mapping_log_pkg.finalize(
                       p_process_id,
                       p_process_name,
                       l_numread,
                       l_numInserted,
                       l_numUpdated,
                       l_numMerged,
                       l_owb_audit_id,
                       l_owb_status
end;
/However, even in this case bear in mind that if you run the mapping in set-base mode, all Oracle returns is the number merged which does not give values for the inserted and updated counts. If you really need those values you need to either a) run in row-based mode or row-based-target-only, or come up with some custom queries. For example, in your pre-mapping do a select count(*) from your_target_table, then run the mapping, then get the number merged, then do another select count(*) from your_target_table. With these values and basic math you could tell the number inserted by the growth in the table, and the rest of the number merged must have been updates.
That being said, if you are playing with dimensions as large as most of the ones I am - there is no bloody way that you want to do two select count(*) statements on each run without a really, really good reason.....
Cheers,
Mike