Monitoring for bw data staging
Upcoming SlideShare
Loading in...5
×
 

Monitoring for bw data staging

on

  • 2,056 views

 

Statistics

Views

Total Views
2,056
Views on SlideShare
2,056
Embed Views
0

Actions

Likes
0
Downloads
101
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Monitoring for bw data staging Monitoring for bw data staging Document Transcript

    • Best-Practice Document Monitoring for BW Data Staging Dietmar-Hopp-Allee 16 D-69190 Walldorf DATE April 2011 SOLUTION MANAGEMENT PHASE SAP SOLUTION Operations Implementation SAP SAP NetWeaver Business Warehouse (BW) Operations & Continuous Improvement TOPIC AREA SOLUTION MANAGER AREA Application management System Monitoring Business process operations System Administration Technical operations Business Process Monitoring© 2010 SAP AG
    • Best-Practice DocumentMonitoring for BW Data StagingTable of Content1 Management Summary 3 1.1 Goal of Using This Service 3 1.2 Alternative Practices 3 1.3 Staff and Skills Requirements 3 1.4 System Requirements 3 1.5 Duration and Timing 32 Best-Practice Document 4 2.1 Preliminary Tasks 4 2.2 Procedure 4 2.2.1 Monitor Data Staging 4 2.2.2 Performance 14 2.2.3 Data Management 16 2.2.4 Data Consistency 233 Further Information 25 3.1 Overview about jobs and tasks 25© 2011 SAP AG page 2/27
    • Best-Practice DocumentMonitoring for BW Data Staging1 Management Summary1.1 Goal of Using This ServiceUse this service to obtain the correct procedures for monitoring your BW system in the area of data staging,uploads and process chains.1.2 Alternative PracticesYou can get SAP experts to deliver this Best Practice if you order the Solution Management Optimization(SMO) service “System Administration Workshop” in the scope of a MaxAttention or Safeguarding Supportengagement.1.3 Staff and Skills RequirementsFor optimal benefit you should make sure that you have experience in the following areas:  Knowledge of standard SAP application and database monitors  Practical experience with the SAP BW Data Warehousing Workbench  Experience with monitoring of data uploads  Experience in job scheduling in an SAP environment1.4 System RequirementsThis document refers to SAP NetWeaver 7.x BW systems.1.5 Duration and TimingMonitoring tasks have to be performed in a BW system on an ongoing basis. The time required for themonitoring tasks depends on the objects being used and the data volume being loaded.© 2011 SAP AG page 3/27
    • Best-Practice DocumentMonitoring for BW Data Staging2 Best-Practice Document2.1 Preliminary TasksBefore performing this best-practice document, ensure that you perform the following preliminary tasks orchecks in the system: Read this Best Practice completely before any given recommendations are implementedWe strongly advise against direct changes in the production environment, and recommend first testing anychanges in a test system.2.2 Procedure2.2.1 Monitor Data StagingFrequency: DailyPlease evaluate the monitoring strategy for the production BW system. If there are reports or data which needto be available at a certain agreed time, then the upload process for this data needs to be analyzed and itshould be decided if it is necessary to monitor the jobs during the night or at the weekend.Uploads and reports should be assigned a business priority status. Then a monitoring strategy appropriate tothe priority can be defined. For example, a high priority report could be the “Daily Logistics Report”. A priorityperiod could be the period end closing.When the monitoring is performed in the morning one hour before the query users start working, this strategyis cost effective and often sufficient for many uploads. However, this may cause severe delays in data andreport availability if priority uploads need to be restarted. In the case of failed extractions it can also mean thatwhen the extraction processes are restarted in the morning it causes an extra load on the source systemduring online working hours.A successful BW monitoring strategy requires close co-operation between both application and basis teams.In BW, in comparison to SAP ERP, these two areas of expertise are more closely linked and the teams areinterdependent. As BW uploads involve extractions in other systems, it is also necessary to ensure thatcommunication and monitoring is as seamless as possible between the BW and source system teams.If the monitoring will be performed by Basis individuals, then further training in BW will be necessary or vice-versa. Close co-operation could mean assigning priority to certain BW jobs and documentation which detailsthe correct course of action and contact people if the job were to fail.Automation methods include adding notification processes (available as standard) to critical Process Chains.Most important BW Monitors are accessible via a central point of entry in the Data Warehousing Workbench(transaction RSA1) – Administration – Monitors:© 2011 SAP AG page 4/27
    • Best-Practice DocumentMonitoring for BW Data StagingThe monitor “BI CCMS” is discussed in detail in the Best Practice Document “Monitoring for BW Basis (ABAPand Java)”, the monitors “BW Accelerator”, “Precalculation Server” and “Aggregates” are discussed in detailin the Best Practice Document “Monitoring for BW Reporting”.The following monitors and tools are important for Data Staging, dependent on your specific scenario tomonitor:2.2.1.1 Workload Monitor ST03© 2011 SAP AG page 5/27
    • Best-Practice DocumentMonitoring for BW Data StagingThe workload monitor in transaction ST03 is useful for general and BW specific performance overviews.In transaction ST03, chose “expert mode”, “BI Workload” and “Load data”. The BW upload part of transactionST03 gives an overview for the different uploads (InfoPackage or DTP uploads) and process chains. Themost important performance indicators for the upload like runtime and data volume are summarized here.The different stages of the upload process, like source system extraction or transformations, are visible andpossible bottlenecks can be identified here.2.2.1.2 Process Chain MonitorFor the application-side analysis of the processes executed via process chain you can use the Process ChainMonitor that is included in the the Data Warehousing Workbench – Administration – Monitors – ProcessChains. Here you have an overview about the progress of your process chains and which process chains arerunning at the moment:© 2011 SAP AG page 6/27
    • Best-Practice DocumentMonitoring for BW Data StagingBy double-clicking on a certain process chain, you jump to transaction RSPC and see an overview about theprogress of the processes of this chain and the process steps executed so far for each process. From hereyou can jump to more detailed monitors of single processes (Upload Monitor, transaction RSMO, ApplicationLog, transaction SLG1) or to the job log of the processes (transaction SM37).2.2.1.3 BW Job Overview in RSM37The BW job overview in transaction RSM37 eases the administration of background jobs “behind“ BWProcess Chains and other BW Jobs through transparency on the involved objects. Transaction RSM37 allowsyou to display background jobs and their BW context (depending on the BW Job):  Process Chain / Process Variant  DTP / InfoPackage  InfoSource / DataSource  Request IDIn this example, the administrator would like to get an overview on all process chain jobs finished, cancelled thor still active on June 5 2008:This selection leads to the following output list:© 2011 SAP AG page 7/27
    • Best-Practice DocumentMonitoring for BW Data StagingThe above output list has to be customized to only show jobs belonging to process chains. Change the layoutand filter on the selection value “chain”:© 2011 SAP AG page 8/27
    • Best-Practice DocumentMonitoring for BW Data StagingThe BW job overview in transaction RSM37 is available with SAP NetWeaver 7.0 BW Support Package(ABAP) 13 = SAP NetWeaver 7.0 Support Package Stack 12. Please see SAP Note “1035318: No overviewof jobs and their program variants”.2.2.1.4 Upload MonitorTo have an overview about all upload processes running on your BW system, you should use the UploadMonitor (Data Warehousing Workbench – Administration – Monitors – Load Data). In the detail-monitor ofeach request (upload process) the progress of this upload and the single process steps are shown. TheUpload Monitor provides all necessary information on times spent in different processes during the load (forexample, extraction time, transfer, posting to PSA, processing transformations, writing to fact tables).If you encounter upload performance problems, try to identify within the upload monitor where the problemresides (for example, transformations):  If the extraction from a SAP source system consumes significant time, use the extractor checker (transaction RSA3) in the source system for further analysis.  If the PSA upload times are unacceptable, check the system for I/O contention because of the high number of writes ( disk layout and striping, DB I/O) and the PSA partitioning configuration.  If the upload bottleneck resides in transformations, please review your coding regarding performance problems. You can use the debug feature in the monitor, SQL trace (transaction ST05) or ABAP performance trace (transaction SE30).If a monitoring during an upload is possible, transaction SM50 can be used to view the running processes.2.2.1.4.1 Decision Tree Upload Performance© 2011 SAP AG page 9/27
    • Best-Practice DocumentMonitoring for BW Data Staging Transaction ST03 Transaction RSMO or RSRQ =>Source system Slow Y Transaction RSA3 Extraction … N Customer exit? Slow Y Hardware bottleneck? Transformation Simulate update N Indexes dropped? DB Access? Y Size of dimension tables PSA/ DB parameterization Cube2.2.1.5 Change Run MonitorFor problems with change runs you can use the Change Run Monitor (Data Warehousing Workbench –Administration – Monitors – Change Run). The Change Run Monitor displays all characteristics that areinvolved in the current change run. It also provides a list of InfoCubes and their associated aggregates thathave already been adjusted as well as those aggregates that still have to be adjusted by the change run. Thechange method, or the way in which the aggregate data is modified, is also displayed. There are threechange methods: Delta, Delta Rollup and Reconstruction.© 2011 SAP AG page 10/27
    • Best-Practice DocumentMonitoring for BW Data Staging2.2.1.5.1 Decision Tree Change Run Monitoring© 2011 SAP AG page 11/27
    • Best-Practice DocumentMonitoring for BW Data Staging Identify long running change runs in your process chains Check Application log (SLG1) and job log (SM37) to identify the critical part Many/large Aggregates Y Review your processed? aggregate design N Check the DB settings, Bad DB Y indexes, no. of performance? partitions, etc. N Change run mode N Check DELTALIMIT (R, D) reasonable? setting2.2.1.6 Real-Time Data AcquisitionFor problems with Real-Time Data Acquisition (RDA) you can use the Monitor for Real-Time Data Acquisition(Data Warehousing Workbench – Administration – Monitors – Real-Time Data Acquisition). Here you see alldaemons that control RDA runs and their current status: Active or inactive. For each daemon you can seewhich InfoPackage, Data Transfer Process and Data Target belongs to it and in which periodicity the data isfetched. You can also see when the last upload happened and how many records the last upload and thecurrently open request contains.© 2011 SAP AG page 12/27
    • Best-Practice DocumentMonitoring for BW Data Staging2.2.1.7 Open Hub MonitorIn SAP NetWeaver 7.x BW systems, Open Hub can be set up as a Data Target for Data Transfer Processes,where the monitoring is fully integrated with the normal upload monitors.Open Hub processing via InfoSpokes is obsolete from SAP NetWeaver 7.30 BW systems onwards. In SAPNetWeaver 7.0 BW systems, Open Hubs that are still being processed via InfoSpokes can be monitored viathe Open Hub Monitor (transaction RSBMO2).2.2.1.8 DataStore Objects OverviewThe Status Overview of DataStore Objects can be accessed via the Data Warehousing Workbench –Administration – Monitors – DataStore Objects. It provides an overview about the loading and activationstatus of the last request to be loaded into each DataStore Object:2.2.1.9 BW Delta Queue MaintenanceThe BW Delta Queue can be monitored with the BW Delta Queue Maintenance (transaction RSA7). The BWDelta Queue for the BW system itself can be accessed via the Data Warehousing Workbench –Administration – Monitors – BW Delta Queue. However please note that this link does not include the BWDelta Queues in the connected source systems. The BW Delta Queues for the source systems have to beaccessed directly via transaction RSA7 in each source system.It is especially important to monitor these queues before release or Support Package upgrades to ensure theBW Delta Queues are empty.© 2011 SAP AG page 13/27
    • Best-Practice DocumentMonitoring for BW Data Staging2.2.2 Performance2.2.2.1 CompressionFrequency: DailyInfoCubes should be compressed regularly. Uncompressed cubes increase the data volume and have anegative effect on query and aggregate build performance. If too many uncompressed requests are allowedto build up in an InfoCube, this can eventually cause unpredictable and severe performance problems.Basically the F-fact table is optimized for writing (upload) and the E-fact table is optimized for reading(queries).A well run and high performing BW system is not possible unless there is a regular compression of InfoCubesand aggregates. A regular compression strategy should be defined with the business data owners. In linewith the requirements of the business process, data in the F-fact table should be compressed regularly. Formore information refer to the documentation in the SAP Help Portal:Technical descriptionDuring the upload of data, a full request will always be inserted into the F-fact table. Each request gets itsown request ID and partition (DB dependent), which is contained in the package dimension. This featureenables you, for example, to delete a request from the F-fact table after the upload. However, this may resultin several entries in the fact table with the same values for all characteristics except the request ID. This willincrease the size of the fact table and the number of partitions (DB dependent) will unnecessarily decreasethe performance of your queries. During compression these records are summarized to one entry with therequest ID 0. Note that once the data has been compressed some functions are no longer available for thisdata (for example, it is not possible to delete the data for a specific request ID).Real-time InfoCubes in a Planning environmentYou should compress your InfoCubes regularly, especially the real-time InfoCubes. In a planning process arequest is closed when the open request contains 50,000 records or when it is switched manually betweenloading and planning mode.For Real-time InfoCubes that are used for planning there is another advantage through compression (onORACLE databases). The F-fact table has a B-tree index and is partitioned according to request ID, whereasthe E-fact table has a bitmap index and partitioning according to your settings (time characteristics). Readaccesses to the E-fact table are faster than those to the F-fact table because B-tree indices are favorable fordata write processes but not for read processes. Please check SAP Note 217397 for details.The planning function “Delete” is used to remove data from the selected planning package. The records arenot directly deleted from the InfoCube. Instead, the system creates additional records with offsetting values.The original and offsetting record are deleted when the InfoCube is compressed.2.2.2.2 Report SAP_INFOCUBE_DESIGNSFrequency: Monthly© 2011 SAP AG page 14/27
    • Best-Practice DocumentMonitoring for BW Data StagingRunning the report SAP_INFOCUBE_DESIGNS shows the database tables of an InfoCube, the number ofrecords in these tables and the ratio of the dimension table size to the Fact table size. If dimension tables aretoo large then they can cause badly performing table joins on database level. Because the data volumegrows and the data allocation changes over the time, this check should be executed regularly.When loading transaction data IDs have to be generated in the dimension table for the entries. If you do havea large dimension this number range operation can negatively affect performance.In the InfoCube star schema, a dimension table can be omitted if the InfoObject is defined as a line item. Thismeans that SQL-based queries become easier. In many cases, the database optimizer can select better runschedules.However, this also has one disadvantage because you cannot include additional characteristics in adimension that is marked as a line item at a later date. This is only possible with normal dimensions. If adimension table has more than one characteristic with a high granularity then consider placing thesecharacteristics into separate dimension tables.Example:A line item is an InfoObject, for example an order number, where one or a few facts in the fact table of theInfoCube are listed.Guidelines How to Limit the Number of Records in Dimension Tables1. If an InfoObject has almost as many distinct values as there are entries in the fact table, define thedimension of the InfoObject as a line item dimension. If defined in this manner, the system will write the datadirectly to the fact table (a field with the data element RSSID, which immediately shows the SID table of theInfoObject, is written in the fact table) instead of creating a dimension table that has almost as many entriesas the fact table.2. Only group related characteristics into one dimension. Unrelated characteristics can use too much diskspace and cause performance problems (for example, 10,000 customers and 10,000 materials may result in100,000,000 records).3. Avoid characteristics with a high granularity meaning many distinct entries compared with the number ofentries in the fact table.4. If you cannot avoid characteristics with a high granularity and most of your queries do not use thesecharacteristics, create an aggregate that stores summarized information. Do not use characteristics with ahigh granularity in this aggregate.Please note that the line item flag can have a negative performance impact on F4 help usage for which thesetting Only Values in InfoProvider is used (transaction RSD1  Tab Business Explorer).5. It is also worthwhile to try the checks in transaction RSRV. Use for example RSRV  All Elementary Tests Transaction Data  Entries Not Used in the Dimension of an InfoCube.ImplementationWhen creating the dimensions as part of InfoCube maintenance, flag the relevant dimension as a line item.You can assign this dimension to exactly one InfoObject. To check which InfoObject has the highestcardinality in the dimension, you can look at the fields of the dimension table highlighted in report© 2011 SAP AG page 15/27
    • Best-Practice DocumentMonitoring for BW Data StagingSAP_INFOCUBE_DESIGNS. For example, Transaction DB02 => Detailed Analysis (Tables and Indexessection) => Enter dimension table name => Check for the field with the most distinct objects.The table below shows as an example a list of InfoCubes with large dimension tables: DIMENSION TABLE NO OF ROWS IN % ENTRIES IN DIMS COMPARED TOINFOCUBE DIMENSION F-TABLEYCCA_C11 /BIC/DYCCA_C114 1.796.665 32YCS_C01 /BIC/DYCS_C011 855.039 532.2.3 Data Management2.2.3.1 Archive DataFrequency: Depending on the retention period of your data.Without archiving, unused data is stored in the database and DataStore objects and InfoCubes can growunrestricted. This can lead to a deterioration of general performance.Establish a BW data archiving project to identify InfoCube and DataStore objects that can be archived. Datastorage also needs to be planned and estimated to determine data storage requirements and the costinvolved. The benefits of BW archiving include:  Reduction of online disk storage  Improvement in BW query performance  Increased data availability as rollup, change runs and backup times will be shorter  Reduced hardware consumption during loading and queriesAn archiving strategy should include the following points and tasks:  Periodical archiving of objects  Estimation of required data storage  Identification of InfoCube and DataStore objects that can be archived  Mapping of Data targets to archiving objects  Validation of archived data  Read capability from archived data  Retention period of archived and deleted data  Time to adjust or rebuild aggregates  Timings for locking the data target whilst deletion is taking place.For more information refer to the SAP Notes 643541 and 653393.Consider the usage of Near Line Storage. Near Line Storage is recommended for data that you may stillneed. Storing historical data in Near Line Storage reduces the data volume of InfoProviders; however, thedata is still available for queries. As Near Line Storage is a third party tool, it might be necessary to schedulefurther periodic jobs for this tool. Further information about Near Line Storage is available in the SAPDocumentation::http://help.sap.com/  SAP NetWeaver  Release  SAP NetWeaver by Key Capability  Information© 2011 SAP AG page 16/27
    • Best-Practice DocumentMonitoring for BW Data StagingIntegration by Key Capability  Business Intelligence  Data Warehousing  Data WarehouseManagement  Information Lifecycle Management  Data Archiving Process© 2011 SAP AG page 17/27
    • Best-Practice DocumentMonitoring for BW Data Staging2.2.3.2 Delete Persistent Staging Area (PSA) dataFrequency: WeeklyDetermine a defined data retention period for data in the PSA tables. This will depend on the type of datainvolved and data uploading strategy. As part of this policy, establish a safe method to periodically delete thedata. If the PSA data is not deleted on a regular basis, the PSA tables grow unrestricted. Very large tablesincrease the cost of data storage, the downtime for maintenance tasks and the performance of data upload.Request deletion is integrated in Process Chains.2.2.3.3 Delete Change Log dataFrequency: WeeklyPlease note that only already updated change log requests can be deleted and that after the deletion areconstruction of requests for subsequent data targets using the DataStore change log will not be possible.Change log requests can be deleted via Process Chains:2.2.3.4 Delete DTP Temporary StorageFrequency: Weekly© 2011 SAP AG page 18/27
    • Best-Practice DocumentMonitoring for BW Data StagingThe Data Transfer Process (DTP) can be set up from the temporary storage in case of a problem. You canview and verify the data in the temporary storage in case of problems.The deletion of temporary storage can be set from DTP Maintenance  Goto  Settings for DTP TemporaryStorage  Delete Temporary Storage:Here you can choose for each DTP:  For which steps you want to have a temporary storage  The level of detail for the temporary storage© 2011 SAP AG page 19/27
    • Best-Practice DocumentMonitoring for BW Data Staging  The retention time of the temporary storage.2.2.3.5 Archive / Delete Administration TablesFrequency: WeeklySAP Note 706478 (and the referenced sub notes) provides an overview of administrative basis tables thatmay considerably increase in size and cause problems if the entries are not regularly archived or deleted.Growing administration tables increase the total size of the system and negatively impact performance, forexample during monitoring the requests.Affected tables are (among others):  Application Log Tables (BAL*)  IDoc Tables (EDI*)  BW Monitoring Tables for requests and process chains  Job Tables (TBTCO, TBTCP)Archive or delete entries in these tables as described in the SAP Note.2.2.3.6 Delete BW Statistic TablesFrequency: QuarterlyThe BW statistic tables RSDDSTAT* and the planning statistic tables UPC_STATISTIC* have to be deletedregularly.Please follow the SAP Notes 211940, 195157, 179046 and 366869 before deleting or archiving.For the BW statistic tables RSDDSTAT*, the deletion of records older than x days can be done in transactionRSA1. To delete data, call transaction RSA1, choose Tools  Settings for BW Statistics’ and select DeleteStatistical Data:© 2011 SAP AG page 20/27
    • Best-Practice DocumentMonitoring for BW Data StagingThe time period for data which should be deleted can now be entered. Please read SAP Note 309955 forinformation on usage and errors in the BW Statistics.For the BPS statistic tables UPC_STATISTIC*, the deletion of records older than x days can be done intransaction BPS_STAT0:© 2011 SAP AG page 21/27
    • Best-Practice DocumentMonitoring for BW Data Staging2.2.3.7 Delete tRFC QueuesFrequency: WeeklyIn BW and all connected source systems, check all outbound tRFC queues (transaction SM58) from time totime to see whether they contain old unsent data packages or Info-IDocs. The reason for these leftoverentries could be that they have already been processed in BW and therefore cannot be processed again orthey contain old requests that cannot be sent following the system copy or RFC connection change.You should then delete these tRFC requests from the queue, not only to reduce the data volume in yoursystem but primarily to prevent you from accidentally sending these old entries again to BW data targets:In the RFC destination (transaction SM59) from the source system to BW, the connection should be set up toprevent a terminated transfer from being restarted automatically and, most importantly, to prevent periodicautomatic activation of incorrectly sent data:© 2011 SAP AG page 22/27
    • Best-Practice DocumentMonitoring for BW Data Staging2.2.4 Data Consistency2.2.4.1 Schedule RSRV ChecksFrequency: Weekly, important checks daily.Use transaction RSRV to analyze the important BW objects in the system. This transaction also providesrepair functionality for some tests. These tests only check the intrinsic technical consistency of BW Objectssuch as foreign key relations of the underlying tables, missing indexes and so on. They do not analyze anybusiness logic or semantic correctness of data.Missing table indexes or inconsistencies in master or transactional data can have a negative impact on yoursystem performance or lead to missing information in your BW reporting.You can schedule the tests in RSRV to be run regularly in the background by defining a specific test packagefor your core business process and needs. Weekly checking (for example on the weekend) should beadequate in general, but important checks (for example missing table indexes) could be also performed on amore frequent basis (daily for example).Another option is to start these checks based on an event (for example tests are triggered after data loading).© 2011 SAP AG page 23/27
    • Best-Practice DocumentMonitoring for BW Data StagingIf you do so, make sure that the application log is checked regularly for the results and the recommendednecessary corrections are made in time.For further information please read SAP Note 619760 containing the latest news about RSRV checks:A detailed description of the test information as to whether repair functionality is available in the check. Whenthe results of the checks are displayed in the application log, you can double click on the message. You willthen see the message again on the right hand side with additional buttons for long texts and details (scroll tothe right side) if applicable.© 2011 SAP AG page 24/27
    • Best-Practice DocumentMonitoring for BW Data Staging3 Further Information3.1 Overview about jobs and tasksThe table below lists all the jobs and tasks discussed in this Best Practice.Area Job / Task FrequencyMonitor Data Staging Workload Monitor ST03 Daily Process Chain Overview Daily BW Job Overview in RSM37 Daily Upload Monitor Daily Change Run Monitor Daily Real-Time Data Acquisition Daily (when RDA is used) Open Hub Monitor Daily DataStore Objects Overview Daily BW Delta Queue Maintenance DailyPerformance Compression Daily Report SAP_INFOCUBE_DESIGNS MonthlyData Management Archive Data Depending on the retention period of your data. Delete PSA data Weekly Delete Change log data Weekly Delete DTP Temporary Storage Weekly Archive / Delete Administration Tables Weekly© 2011 SAP AG page 25/27
    • Best-Practice DocumentMonitoring for BW Data Staging Delete BW Statistic Tables Quarterly Delete tRFC Queues WeeklyData Consistency Schedule RSRV Checks Weekly, important checks daily.© 2011 SAP AG page 26/27
    • Best-Practice DocumentMonitoring for BW Data Staging© Copyright 2011 SAP AG. All rights reserved.No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9,iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server,PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX,Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporatedin the United States and/or other countries.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer and other SAP products andservices mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and othercountries.Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, andother Business Objects products and services mentioned herein as well as their respective logos are trademarks or registeredtrademarks of SAP France in the United States and in other countries.All other product and service names mentioned are the trademarks of their respective companies. Data contained in this documentserves informational purposes only. National product specifications may vary.The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provideany warranty whatsoever relating to third-party Web pages.© 2011 SAP AG page 27/27