ISSUE :

Time zone difference causes incorrect data loading from data source -   0CSM_CASE_ATTR.

SOLUTION:

The case extractor 0CSM_CASE_ATTR is being used by many customers successfully with no issues in data extraction. 

In the extractor 0CSM_CASE_ATTR the default time zone is UTC. This is the architectural design where all time fields in the Basis Case Management application are in UTC format. The table SCMG_T_CASE and SCMG_T_CASE_ATTR would have all time fields in UTC format during save/retrieval or any other operation.

In the extractor 0CSM_CASE_ATTR we use the ABAP statement 'CONVERT DAT' which converts the timestamp from local time zone to UTC format. No other format would be supported because then it would cause inconsistencies with the database.

Initially in a similar issue reported by another customer we first were exploring the idea of increasing the time range interval in RSA2 transaction in the customer system directly. But then this range has been set from beginning and has worked fine for all the customers till now. So the issue would not be resolved by this action.

Below notes explain about the Time Zone issues ~
198411  - Current data and information about time zones
741734  - Incorrect times due to the time zone settings
481835  - Analyzing the time zone settings
101726  - Incorrect times and time zone setting
15913    - Timezone problems (local vs. global time)

Refer to the below notes which talk about Daylight Saving issues ~
126692  - Daylight saving time rules are incorrect
102088  - Reducing downtime when changing from summer to winter
7417      - Conversion between winter time and daylight saving

Go through each of the notes in detail (most would have manual instructions to be performed and nothing should be skipped as it could result in inconsistencies).

Additionally if after applying all the above notes the issue still persists then the below notes would be useful -
<1> For issues on CRM cases refer to note ~
       1470994  - 0CRM_CASE_ATTR: additional fields
<2> For issues on Basis Case extraction refer to notes ~
       1281000  - retrieval of data from case extractor taking a lot of time
       1159696  - Not able to get the data using case type from case
       996360    - Case Extractor not able to pull more than 1 data package.

I would like to introduce a new method to identify the URL generated by the system to access the Planning Modeler.

The planning modeler uses SSO (e.g. http://<server>/sap/public/myssocntl?sap-client=000). For that reason, ou cannot access the Planning Modeler URL directly from your default browser.

This procedure is very useful in case of Planning Modeler does not start or, in a urgent case, to access without SSO.

• Go to transaction SE24 and display the class "CL_RSPLS_WDPP"
• Open the method "start_wdapp"

•   Add a breakpoint on the code line:

  l_url = get_url(
      i_dc = i_dc
      i_application = i_app
      i_params = i_params ).

• Go to transaction RSPLAN
• Active the Debugging mode with  /h  on transaction box.
• Click on "Start Modeler" button
• The Debugger will start and will stop on the break-point.
• Press F6 and check the "l_url" content. Its value is the Planning Modeler URL configured for that system.

Ok, once again reproducing a problem takes a lot of (waiting-)time for the query to finish.

In the meantime I can also just write a super-short-blog post about a pretty common BW-on-Oracle performance hitch:
Inappropriate database optimizer statistics.
(yes, 'inapropriate' not 'outdated'!)

Usually, that means: if everything runs as it is supposed to, BW will take care of collecting the CBO statistics whenever large changes to the data are performed (e.g. data had been loaded or condensed, etc.).
Of course, the BW admin has to set this up in process chains or as attributes to infoproviders but usually, this works well.

If these BW-measures somehow "forget" to update the statistics when new statistics would be required, there is still the daily "Update Optimizer Statistics" (brconnect -f stats) run that should cover this.

The big exception

Unfortunately there is one setting available that prevents the update of new statistics:
the exception table DBSTATC.

In this table you can setup statistic gathering parameters that deviate from the default build-in behavior of brconnect. (This behavior is not too complex, but really does cover most SAP specifics. See the documentation for details here).

One of the most used exceptions here is to avoid gathering new statistics at all.
This can be useful, e.g. when a table is very volatile and you don't want to have your access plans changed all the time because the statistics sometimes report a small/emtpy and sometimes a large table.
(For such case SAP even provides pre-defined table statistics, check sap note 756335 on that)

But what does this have to do with BW?

Well, before brconnect there had been a different tool called SAPDBA and this tool wasn't able to cope with BW objects.
Therefore BW development decided to build its own statistics update coding and to prevent SAPDBA from messing around with the BW tables. And for that they created entries in DBSTATC with ACTIVE=I automatically.

A comfortable solution

This is of course all long past now, but these entries seem to have survived many system upgrades.
In order to get rid of them, there's a report available: SAP_DBSTATC_CLEANUP.
With it you can display and delete the DBSTATC entries for single infocubes or all of them.
Looking at the sap note that introduces this report (SAP note 129252) you'll find that this had been around for quite a while now :-)

The recommendation is of course to remove all the DBSTATC entries for BW objects, so that the standard statistic gathering can be performed.
SAP note 1013912 - "FAQ: Oracle BW Performance" already contained this recommendation and from today on, it also contains the report name ...

And yes, the solution is to remove the entries and not to set ACTIVE=A or something like that. DBSTATC really is all about defining an exception. If the tables should be handled the standard way, then DBSTATC should contain any entry for them!

Ok, the customer report is through... back to the real work!

Best regards,
Lars

There are several places across BW tools from where clearing of different types of cache can be done. 

BEx Web Application Designer metadata cache: stores metadata information about objects related to web templates. You can also delete the cache in which metadata information belonging to current opened template within the session to BW backend. To delete this cache choose in BW Web Application Designer: Menu Tools -> Setting -> Delete cache -> Delete cache. Documentation for NW2004 can be found here. This is not valid for BW based on version 7.x.

OLAP Cache: so called Query cache is type of cache is used to buffer BW queries data sets to be available for next query run. In this case OLAP processor first checks cache and do not need to read the data out of BW infoproviders. To clear OLAP cache run TA RSRT -> Cache monitor -> Delete or you can go via TA RSRCACHE. Online docu here. If you want to do it from your custom ABAP program you may use function module: RSR_CACHE_CLEAR_ALL_CACHES. 

HTTP server cache: this is related to HTTP server build in SAP AS server. You can clear it via TA SMICM -> Goto -> HTTP server cache -> Invalidate cache -> Global in system. Online docu here.

In the second week working in BW support I noticed that there was a problem reported by customers again and again.
The customers complained about "database statistics update fails in process chains" or "brconnect run returns errors".
When checking the relevant log file entries for the actions there was always something like

ERROR at line 1:
ORA-20000: index "SAPR3"."/BIC/F100069~900"  or partition of such index is in unusable state
ORA-06512: at "SYS.DBMS_STATS", line 15181
ORA-06512: at "SYS.DBMS_STATS", line 15203
ORA-06512: at line 1

The more database savvy customers or DBAs sometimes had a quick resolution at hand: to rebuild the index.

And, indeed, after rebuilding the affected index (as I realized it was nearly always a 900 index) the statistics could be correctly gathered.
Problem solved, or not?

Well, only until the next compression run for the infocube happened.

Infocube compression, wait, like infocube.zip or what?

The term 'compression' is a bit misleading here and 'to condense' seems more appropriate.
To understand this action, we've to take a look into how fact table data is managed in SAP BW.
If you're yet unfamiliar with the BW-star schema (extended star schema) it might be a good idea to check the documentation or the BW related blogs and WIKIs here at SDN.

The fact tables are used to store the actual business data that should be reported on to. In the simplest case, this data is loaded from the source system (e.g. the ERP system) on a regular basis, say daily.
So, we get new data in more or less large chunks or packets.
The BW term for this is 'request'.
A data request is a specific chunk of data that only has one thing in common: it has been loaded into the fact table together. [more on this]

Requests and what they are good for

This request wise processing provides several options that are otherwise quite hard to achieve in datawarehouse systems:

• we can load just the data that had been changed since the last load (delta loading)
• we can check the data after each load for technical and quality issues and decide wether or not it should occur in the reporting
• in case some of the data was not imported correctly, we can easily delete it again, without impairing the reports that use the already available data.

If you think about it, this means, that it's totally possible to load information about the same business objects (let's say: direct sales to high level customers in southern germany) can be loaded several times.´

If you load the sales transaction data every day to later on report it on a weekly base then you'll get the the sum of all the sales aggregated over a week - and use data of 7 requests work of data (1 request per day, 7 days a week).

But as we see, for our reporting requirement (sales on weekly base) it's actually not necessary to keep all the data load pakets (requests).
Once we are sure about that the data is technically and quality wise OK, then we might just as well sum up the data to the weekly level, store this and throw away the 7 requests.
This is what the compression of Infocubes pretty much is about.
In SAP BW this is implemented based on two tables:
the F-facttable to which all data load requests go and the E-facttable, which contains the information for the pre-aggregated (condensed) data. [more on this]

Getting closer...

On reporting time, the SAP BW OLAP engine knows about the fact that our data is stored in two tables.
So for every BW query against an Infocube, we usually see TWO nearly identical SQL statements, that only differ in the facttable that is actually used.

Now we have:

• two tables,
• we've data that needs to be read and aggregated request-wise from the F-facttable,
• we've the aggregation result that has to be saved in the E-facttable
• we've data that afterwards needs to be deleted from the F-facttable - otherwise some numbers would be included twice in our report!

Looking at this database requirements, there's an Oracle feature available, that really is made for it (it really is ;-)): PARTITIONING!

Without partitioning the final deletion of already condensed requests would require to

• scan at least one full index in order to find all rows matching the requests to be deleted,
• remove them
• and update the indexes afterwards.

With partitioning all we've to do is to drop the partitions that contain our request.
That's the reason why the F-facttables are always partitioned based on the request dimension (on DBMSes that support partitioning, of course)

So, we can easily get rid of data, when the table is partitioned the right way.

But what about the indexes?

There's a treat in Oracle available for that as well: local partitioning of indexes.
Simply put this means: for every table partition a corresponding partition is created for the partitioned index.

With this, we don't even have to rebuild the indexes after dropping a table partition.
All we've to do is to also drop the corresponding index partition together with the table partition.
The remaining index will still be completely correct and will still cover all data in the table.

Ok, now we arrived at the start of the problem ;-)

All this sounds quite good.
In fact, it's great!
And (of course) here begins the problem.

This great combination of clever data design, implementation and database feature exploitation only works properly if the indexes really are partitioned exactly as the table is.
So BW has to take care of this since Oracle allows to create indexes with a different partitioning scheme or without partitioning as well.
If this is the case and we drop table partitions, then Oracle would have to read every row of the dropped partition to know every deleted row and take this information to maintain the index data.
Obviously this would render the partition advantage null and void.
So, Oracle simply flags all indexes for which the same drop partition cannot be performed as UNUSABLE.

Such UNUSABLE indexes can be repaired simply be rebuilding them.
The Oracle cost-based optimizer is clever enough to ignore those indexes (also see oracle parameter "skip_unusable_indexes"), so queries will not fail because of this.

Except... except we force Oracle to use the broken index by using a hint.

"Where the heck to we do such stuff?" - is that the question you've got in mind right now?

Well, we do it everytime you run the update statistics job.
And collecting CBO statistics after deleting lots of data from a central fact table in BW is usually done as part of the data loading process (chain).

In Oracle update statistics means calling a PL/SQL stored procedure in the DBMS_STATS package. And in there, Oracle will run SQL statements like this:

select /*+ no_parallel_index(t,"/BIC/F100069~900") dbms_stats cursor_sharing_exact use_weak_name_resl dynamic_sampling(0) no_monitoring no_expand index(t,"/BIC/F100069~900") */ count(distinct sys_op_lbid(15948,'R',t.rowid)) as nrw ,count(distinct sys_op_lbid(15948,'L',t.rowid)) as nlb ,count(distinct "KEY_IC_0025P") as ndk ,null as clf from "SAPR3"."/BIC/F100069" t where TBL$OR$IDX$PART$NUM("SAPR3"."/BIC/F100069",0,4,0,"ROWID") = :objn

p>No reason to understand the whole statement for now, but the important part here is the INDEX hint.
With this hint Oracle is forced to use the index (for which statistics should be collected).
If our index is UNUSABLE at this point in time, then Oracle has no other choice as to report:

ERROR at line 1:
ORA-20000: index "SAPR3"."/BIC/F100069~900"  or partition of such index is in unusable state
ORA-06512: at "SYS.DBMS_STATS", line 15181
ORA-06512: at "SYS.DBMS_STATS", line 15203
ORA-06512: at line 1

LOOOONG story short.

Mashing all this together:

WHEN

        we've a partitioned table with a non-partitioned index

AND

       we drop a partition of the table, so that the non-partitioned index is flagged UNUSABLE

AND

       when we finally run an update statistics on this table,

THEN

       we end up with our ORA-20000 error message.

Why do I tell you this, when BW does take care of the database objects so well?

Because sometimes it fails to do so.
One reason for such a failure is a bug that has been introduced with a SAP Basis SP.
This bug is already fixed with sapnote 1479683 but there are many customers around who haven't yet installed the note and who are just facing miraculous errors in their info cube compression process chains.

As you can see the connection between the ORA-20000 error message about the unusable index and the real cause is rather a long distance one, although straight forward once you undertand it.

The solution (ahem... TATAAA!)

To finally get rid of this problem, I wrote note #1513510.

In there you'll find that you have to
a) import the fix for the SAP Basis bug (note #1479683)
b) recreate (NOT just rebuild) the indexes

For step b) the easiest and quickest way is to use the same function modules that SAP BW does use for the this task.

Excurse... Aggregates are just little infocubes...

In note #1513510 I included an SQL statement to find all partitioned tables for which there are non-partitioned indexes, so that the DBA or BW-Poweruser can look up the problematic ones without having to wait for process chains to fail.
The statement looks like this:

select 
    /*+ 
    no_parallel_index(t,"/BIC/F100069~900")
    dbms_stats 
    cursor_sharing_exact
    use_weak_name_resl 
    dynamic_sampling(0) 
    no_monitoring 
    no_expand 
    index(t,"/BIC/F100069~900") 
    */ 
 count(distinct sys_op_lbid(15948,'R',t.rowid)) as nrw
,count(distinct sys_op_lbid(15948,'L',t.rowid)) as nlb
,count(distinct "KEY_IC_0025P") as ndk
,null as clf 
from 
    "SAPR3"."/BIC/F100069" t 
where 
    TBL$OR$IDX$PART$NUM("SAPR3"."/BIC/F100069",0,4,0,"ROWID") = :objn

If you run this statement you may come across tables like /BIC/F100234.
But you don't have any Infocube named "100234" - so what are those tables about?
They belong to aggregate infocubes. [more on this here]
These are (small) subsets of data that the OLAP processor can choose to deliver the reporting result much quicker. In this respect aggregates are very much like database indexes.
Since the aggregates really are subsets of the actual large infocube they have an F- and E-facttable as well and the same problem can occur wich them as well.

If you now want to know to which infocube a specific aggregate belongs to, you can easily look it up in the RSAGGRDIR table.
For every aggregate you'll find an entry with in the table that maps the aggregate to the infocube.

Checking this table in SE16 delivers an output similar to this:

Table:          RSDDAGGRDIR

   AGGRUID                   OBJVERS INFOCUBE   AGGRCUBE ...
                                                         ...
   03T89W5IUUEFPARPLPZ29YZF3 A       0BWVC_AGV  100108   ...
   200H0IWIR23WASLOESNT8BKJZ A       0BWVC_AGV  100099   ...
   3VILFVABC6MYNF9R10M0WYVHR A       ICD05      100772   ...
   3VIVFYBTHUCH8HF58HQCRGJXS A       ICD03      100778   ...
   3VIVG4AW8R8BQ0JPRVJWKZJZK A       ICD03      100779   ...
   3VIVG8ZVTWHX3SFLC8ZEQ6RQO A       ICD03      100780   ...
   3VP09ETI53LHVKWQHLL79RK5X A       RSDRICUBE  100032   ...
   40VXFTXRAJ6NNT88CWOEA3LYN A       0BWVC09CP  100071   ...
   40VXFU60ZFEEYGCAFPLSI952N A       0BWVC09CP  100072   ...
   40VXK7M8IUTH0IH052QGOF94F A       0BWVC09CP  100073   ...
   [...]
   

Ok, I hope some of you really made it to the end of this rather lengthly first BW blog post. I'll try to keep them shorter in the future ;-)

regards,

Lars

SAP NetWeaver BW 7.30 provides you with a new metadata and transport object for BW data flows. This functionality enables you to persist the data flow views that you created with the ‘Display Data Flow’ function. Data flows are integrated as trees into the Data Warehousing Workbench. They are created and maintained in the same graphical design environment that you will be familiar with from transformation and process chain maintenance screens, for example.

A data flow provides a constant view of objects in the system. You can integrate existing objects and create new objects. The data flow maintenance screen can be used as a single point of entry for future development of your Data Warehousing objects and you can use the dataflow functionality to organize your projects.

Next I want to give you a short demonstration of some of the user-friendly modeling capabilities of data flow maintenance. I will also show you how  to model a data flow from a source to a target, based on existing objects or by creating new objects. I have modeled the following sales scenario: The USA data is sent from a DataSource via a DataStore object to the USA Sales InfoCube. The same setup applies to the Europe data, but the data comes from three DataSources. The USA InfoCube and Europe InfoCube are combined using a MultiProvider for reporting.  Let’s assume that some of the objects are already available and others have to be created from scratch.

Let's start in the data flow tree of the Data Warehousing Workbench. We create a new data flow using the InfoArea context menu and enter the name and description of the data flow. We save the empty data flow and the object appears in the tree. Then we drag and drop the icon of the object that we want to create from the toolbar to the data flow maintenance area. We start with the DataStore object, the InfoCube for Sales Europe and the MultiProvider.

We have now created three non-persistent objects. This means that the objects only exist locally in this data flow and not in the database. Now we draw two lines from the DataStore object to the InfoCube and one line from the InfoCube to the MultiProvider.

What happened? When you drew the line from the DataStore object to the InfoCube, the system realized that the line was a transformation and created a non-persistent transformation. When you drew the second line, the system created a data transfer process (DTP) because a transformation already existed. Further lines would result in further DTPs. When you drew a line from the InfoCube to the MultiProvider, the system created a simple line. This indicates a contained-in relationship, which is the only valid possibility in this case.

Next we used the undo and redo buttons that allow you to undo and redo your previous actions. The screenshots below show the result of the last four actions being undone. In this case, the three connections as well as dragging and dropping the MultiProvider are reversed.

To redo your actions, simply open the dropdown menu of the redo button and select the required action or press the redo button four times, for example.

Before we move on, we’ll assign a technical name and description to the InfoCube by choosing the change option in the context menu. Note that this option does not physically create the InfoCube in the system. The InfoCube is still a non-persistent object that is saved locally in the data flow.

The Sales Europe DataStore object exists already in the system. We add it to the data flow by choosing a command from the context menu of the non-persistent object:

Choose the DataStore object ‘Sales Europe’ in the value help. The system adds the object to the data flow maintenance screen and changes the background color of the node to blue. This indicates that the node represents an existing persistent BW object.

Next we create the Sales Europe InfoCube by double-clicking on the non-persistent object. The dialog box for creating InfoCubes opens. The DataStore object is selected as the InfoCube template because it is connected to the InfoCube. The description and technical name of the non-persistent object are applied to the InfoCube.

Activate the InfoCube and create the transformations and DTPs by double-clicking on the appropriate connections. The source and target are already specified. You simply need to maintain the details. Activate the objects.

Now we need to integrate Sales USA (already exists in the system) into our data flow. We start by dragging the existing Sales USA InfoCube from the InfoProvider tree and dropping it onto the MultiProvider. The existing InfoCube is added. Since the target is the MultiProvider, the system creates a connection between the InfoCube and the MultiProvider, based on the algorithm explained above.

To integrate the entire data flow of the Sales USA InfoCube, expand the existing data flow of the  InfoCube by choosing the menu entry ‘Use data flow of object’. A dialog box opens. Specify whether you want to use the data flow upwards, downwards or in both directions. The data flow is shown in a separate window and can be added to the data flow maintainance by pressing the confirm button.

The objects of the data flow are now integrated in our data flow. Double click on the MultiProvider to open the MultiProvider maintenance screen. Here the source objects are listed due to the connections and are already selected in the MultiProvider maintenance. Simply complete your MultiProvider and activate it.

Connect three European Sales DataSources to the DataStore object by selecting multiple DataSources in a Data Warehousing Workbench object tree and dropping them onto the DataStore object. The transformations are automatically created (as mentioned above).

The Sales data flow scenario can be completed by drawing links for the DTPs and maintaining the details for transformation and DTPs.

This document gives you a first impression of what is possible with the new data flow maintenance. Note that this is only part of the functionality. Some additional features are listed below. A very important function is described in a separate document: Creating and Using Data Flow Templates.

• If the data flow is collected for the transport, all relevant objects are also collected.
• You can copy data flows with the data flow copy wizard by performing a simple copy or a multiple deep copy.
• You can use the create data flow wizard to generate parts of your data flow.
• Semantically partitioned objects are supported in the data flow maintenance
• You can collect and integrate all DTPs and/or transformations that belong to objects in the data flow by selecting a single option. For example, if you start your data flow with a list of InfoProviders and you want to display all transformations that connect objects to other objects of this object set.
• …and many more features.  Try it out!

Scenario:

• DSO/InfoCube having very large number of entries > 10 million entries
• Database is Oracle
• Customer is adding new fields to the DSO/InfoCube and transporting the changes to the Production system.

Background:

Whenever the changes like
a) Adding new key figures
b) Adding new characteristics and dimensions.

are performed on an object (DSO or InfoCube) which already contains data, the activation process has to adjust the table(s) structure. This adjustments process has to alter the table by adding new column and initialize the column to "NOT NULL" and with initial default value. This should work without any problems given the fact that there are enough database resources to perform this change on the database.

Adding not null fields requires checking of the entire "existing" data for null values which requires large amount of space in the transaction log and in the database and comprise many I/O operation. Depending on I/O throughput of your storage it takes hours.

Reason for initializing the newly added column is that from BW reporting and extraction point the column has to be not null and initialized with default value, as BW can not handle null values. General recommendation in such cases where it is required to remodel the object by adding new fields where there is already much data is to follow the below workaround.

The general workaround involves making a copy of the existing data in the cube using datamart interface or Open Hub services. For example
1. Make copy of the existing Cube (Cube1) to Cube2
2. Add new fields to Cube2
3. Load the data from Cube1 to Cube2 using datamart (use Cube2 for further purposes.

If you have some reporting queries defined on Cube1 then need to do the following

1. Make copy of the existing Cube (Cube1) to Cube2
2. Load data from Cube1 to Cube2 using datamart
3. Delete Data from Cube1
4. Add new fields to Cube1
5. Reload the data from Cube2 to Cube1 using datamart

Alternative Solution:

An alternative to this solution is SAP Note 1287382 which observed to be much faster than the normal process.

1287382 Extending BW objects on Oracle with large tables

We have observed a significant performance improvement using this SAP Note although the implementation of this SAP Note, require good application knowledge.

Here are the steps for your reference:

1. Have a list of the large DSOs (identify the size of active table, change log table) and InfoCubes (identify the size of E, F table).
2. Archive or clear change log tables, compress the InfoCubes, minimize the number of records in the tables.
3. Have a list of objects to be transported, identify the dependency of the objects, create the change requests (try to group large DSOs and InfoCubes into separate change request), identify the sequence of the transport.
4. Check the current SP level and implement SAP Note 1287382 and correction mentioned in the SAP Note 1340922.
5. Run program SAP_RSADMIN_MAINTAIN, maintain the RSADMIN parameters as mentioned in the SAP Note 1287382.
6. Schedule background job to run program SAP_NOT_NULL_REPAIR_ORACLE with suitable parameters (table name, parallelism). More parallel processing could be scheduled depending on your hardware capacity. For InfoCubes, the job has to run separately for all the DIM tables and Fact tables.

Job SAP_NOT_NULL_REPAIR_ORACLE
- Renames the table name (/BIC/AMYODS00) to (/BIC/AMYODS00_OLD)
- New table /BIC/AMYODS00 is created in the system and new fields are added to this new table
- Data from the /BIC/AMYODS00_OLD is copied to the newly created table /BIC/AMYODS00

7. Ensure that Job in SM37 is successfully executed.
8. If any errors occur observed in SM37:

The program fails before copying :- Check whether "/BIC/AMYODS00_OLD" exists. Normally, however, this should not be the case because, if errors occur, "/BIC/AMYODS00_OLD" is renamed "/BIC/AMYODS00". If the table exists, before the program is restarted, the table "/BIC/AMYODS00" must be dropped (!!! MUST NOT CONTAIN DATA) and "/BIC/AMYODS00_OLD" becomes "/BIC/AMYODS00".
1.) Drop the new empty table "/BIC/AMYODS00" (using SE14 or SQL: DROP TABLE "/BIC/AMYODS00")
2.) Rename "/BIC/AMYODS00_OLD" to "/BIC/AMYODS00" (must be done with native SQL )
3.) Update in DD03L at least one column to nullable

The program fails after copying: - If the number of records in "/BIC/AMYODS00_OLD" and "/BIC/AMYODS00" differ.

- ANALYSIS and repetition in accordance with the previous step (The program fails before copying). /BIC/AMYODS00_OLD should have complete data in the table.
The program should not be restarted. Instead, the remaining steps (structuring an index and structuring statistics) are carried out manually after the error analysis.

9. Drop *_OLD tables if the conversion is successful.

If the DSO/InfoProvider is contain more than 10 million entries, the above alternative solution should help to reduce the amount of time significantly.

You might know and appreciate the capabilities to generically define delta when building a DataSource in SAP source systems. But you had a lot of work, if you want to load delta data from any other source system type, like DBConnect, UDConnect or File. You could declare the data is delta, ok, but this had no real effect, it was just declarative. The task to select the correct data from the source was still yours.

Now with BW 7.30 this has changed. Because now there is – the generic BW delta!

As expected, you start by defining a BW DataSource.

Nothing new, up to now. But if you choose that this DataSource is delta enabled, you will find a new dropdown:

These are the same options that you already know from the SAP source system DataSource definition:

Ok, let’s see what happens if we select “Date”.

The fields “Delta Field” and the two interval fields you know already from the generic delta in the SAP source system. And they have the same meaning. So hopefully I can skip the lengthy explanation of the Security Margin Interval Logic and come to the extra field which popped up: The Time Zone. Well ok, not very thrilling, but probably useful: Since the data in your source might not be saved at the same time zone like the BW which loads it (or your local time), you can explicitly specify the time zone of your data.

“Time stamp – short” offers quite the same input fields, except that the intervals are given in seconds rather than days. “Time stamp Long (UTC)” is by definition lacking the “Time zone” field. Let’s watch “Numeric Pointer”:

Oops – no Upper Interval! I guess now I do need to spend some words on these intervals: The value given in “upper Interval” is subtracted from the upper limit used for selecting the delta field. Let’s say current upper value of the delta field is 100. The upper interval is 5. So we would need to select the data up to value 95. But hold on – how should the system know the current value of the numeric field without extracting it? So we would extract the data up to the current upper value anyhow – and hence there is no use in specifying an upper interval.

The lower limit in turn is automatically parsed from the loaded data – and thus known before the next request starts. And hence we can subtract the safety margin before starting selection.

Our example DataSource has a UTC time stamp field, so let’s select it:

Activate the DataSource and create an InfoPackage:

CHANGED is no selectable field in the InfoPackage. Why not? Well, the delta selections are calculated automatically. You do not need to select explicitly on them. Now let’s not forget to set the update mode to Init in order to take advantage of the generic delta:

Wait a minute! There is a new flag: “Switch InfoPack. in PC to Delta (F1)”. Guess I need to press F1 to understand what this field is about.

Sounds useful, doesn’t it? No more maintenance of two different InfoPackages and process chains for delta upload! You can use the same InfoPackage to load Init and Delta like in the DTP.

In our small test we do not need a process chain, so let’s go on without this flag and load it. Then let’s switch the InfoPackage to Delta manually and load again.

Indeed, there are selections for our field CHANGED.

Don't miss any of the other Information on BW 7.30 which you can find here

 
http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/20413%3Futm_source%3Dtwitterfeed%26utm_medium%3Dtwitter%26utm_campaign%3DFeed%253A+SAPNetworkWeblogs+%2528SAP+Network+Weblogs%2529

===========================================================================================================

호오!! 테스트해보고 싶!