RSRT, RSRV Testing

Hi Friends,
Can any one please tell me.
Do we have any danger if we use all sort of functionality in RSRV , RSRT for BW objects or Report in Production server. Some times i am feeling that it is harmful when i do things things like repiar..But i donot know..
Please tell me if any limitations are available??
Thanks
Tony

It depends on what you are changing or playing around with.
For RSRT, it's great for testing Queries with. You can also change the performance of a query under the 'Properties' tab.
If you switch the Read Mode to 'A' - 'Query to Read All Data at Once', it can really kill the query performance. Instead of reading data with each navigation, it reads it all before it loads. It will speed up navigation after the report has rendered, but kill the load time.
The 'Generate Report' button can be used with the report has become corrupt. It will regenerate the report. It hasn't happened many times, but I've had reports that just failed to run when no change has been made. Regenerating the report fixed it.
Execute + Debug is a lifesaver when you need to trace user exits in your report. It has a lot of neat options.
RSRV can help you find problems with your InfoProviders. Just last week, one of my ODS objects had a bad activation. I was able to run an analysis and allow the system to correct my error. If you are unsure of the change, you can always not 'correct error' and view the log of the analysis.
Michael
Assign pts if you found any of that useful.

Similar Messages

RSRT & RSRV

Hello,
What r these transactions and when and for what are they used? in which scenarios they are used?
regards,

Hi Aby,
RSRT is used for monitoring query execution (performance, debug, etc.)
RSRV is used to analyse consistency and repairing of BW objects (InfoCubes, ODS, PSA, Master Data, etc.).
You will use RSRT to get technical information on a query when you perform some tuning for instance (use of cache and related aspects).
You will use RSRV to check objects when you get errors (example: missing SID's) or when you want to make an audit of your BW system for possible problems or before a major upgrade, etc.
Hope it helps a bit.
LauQ

RSRV test gives error

Hi experts,
When i ran RSRV for 0sold_to chracr i am getting this error..
has anyone faced a similar errror. i tried to correct error, but it still appears.Pleae help me.
Characteristic 0SOLD_TO: 97 values from table /BI0/PCUSTOMER do not exist in table /BI0/SCUSTOMER
Thanks,
DV

Note 1277442 "No new data after repartitioning (SID field is empty)" has solved a problem

RSRV test fails with characteristic 0UNIT

RSRV shows an error with characteristic 0UNIT.
Two common units of density, copied from R/3, are being flagged as errors.
µGL and µGQ are being rejected as "Value for characteristic 0UNIT not permitted".
Anyone have any idea why?
Several OSS notes out on this problem, but they should be included in our current release.
SAP_BW 7.0, SP 11
SAP_BASIS 7.0 SP 10
SEM_BW 6.0 SP 07
THANKS for any help offered.

Problem Solved
For the three entries of the 0UNIT characteristic (chabasnm) in the RSDCHABAS table, enter an X in the LOWERCASE field (Transaction SE16).
Note 853569

When do u go for elementary test and combined test(rsrv)

hi all,
Can anyone explain me with an realtime scenario ? when do we go for elementary test in rsrv trns code and combined test.
thanxs
hari

hi hari,
RSRV is used for analysis and repair of all BW objects.You can perform consistency checks on the data and metadata stored in BW System.RSRV tests the foriegn key relationships between the individual tables of the enhanced starschema of the BW system
There are 2 types of tests
1.Elementary Tests- these tests are related to master data,transaction data,ODS objects,Hierarchies.database(indices,parametres,statistics),aggregates,PSA tables and documents.
2.Combined Tests-This test determines which elementary tests are performed according to the parametres entered.
Hope this helps!
partha

GIVE ME DETAILS FUNCTION ON T CODE RSRV DETAILS

GIVE ME DETAILS FUNCTION ON T CODE RSRV DETAILS

Hi,
RSRV is a diagnostic tool in BW, System will automatically corrects if there are any inconsistancies with the BW objects
It is used for Analysis and Repair purpose of BW objects like:
1. Master Data Consistency Checks
2. Transaction Data Consistency Checks
3. Size of Dimensio tables
4. Checking SID values
5. PSA duplicate record check
6. Checking Aggregates
7. Partitions of Info cuses etc...
You can check everything.
Just expand it > drag n drop the required test to the right panel and give the object > execute.
Transaction RSRV: BI Data and Metadata Test and Repair Environment.
Transaction RSRV checks the consistency of data stored in BI. It mostly examines the foreign key relationships between individual tables in the enhanced star schema of the BI system.
The transaction interface was re-designed for SAP BW release 3.0A. The following provides an introduction to running the transaction.
Starting the Transaction
You can reach the test and repair environment:
by entering the transaction code RSRV
in the SAP Easy Access Menu under SAP Menu -> Administration -> Analysis Tool>/>
from InfoObject maintenance (transaction RSD1)
from transaction RSD1 by choosing Analyze from the initial screen.
in the maintenance screen for a characteristic by choosing Edit -> Analyze InfoObject from the main menu.
The Initial Screen
When using the test and repair environment for the first time, the message "Values were not found for all setting parameters" draws your attention to the fact that there are not any saved settings for your user.
After confirming the dialog box, you reach the initial screen of the transaction. This is divided into two parts:
1. On the left-hand side, you can see a tree structure with the pool of available tests.
2. The right-hand side is empty at first. The tests you have selected will be put here. A selection of tests is called a Test Package here.
Combined and Elementary Tests
An Elementary Test is a test that cannot be divided into smaller tests and can therefore only be executed as a whole (or not at all).
In this regard, a Combined Test determines which elementary tests are to be executed after entering the parameters. You can remove individual elementary tests from the test package before carrying out the actual test run, in order to reduce run time, for example.
Combining a Test Package and Executing it.
Firstly select one or more tests with drag&drop or by double-clicking. Each selected test appears as a closed folder in the view of your test package. (An exception is elementary tests without parameters: These do not appear as a folder). You can also drag a whole folder of tests from the test pool across to the right-hand screen area; all tests that are located in the hierarchical structure under this folder are then added to the test package. You can also display a short description of the test, if required. Do this right-clicking on a test and choosing "Description" from the context menu.
Afterwards, you must supply the tests with parameters. Tests without parameters must not be given parameters. You are given notification of this when selecting them. You can enter parameters by double-clicking on a test (test package) or by opening a test folder.
A popup appears in which you have to enter the required parameter values. Often, there is value help available. After the parameters are entered, a folder with the name Parameter is added under the test. This contains the parameter values. The test name can change in some circumstances, enabling you to see at first glance for which parameter values the test is to be executed. It is possible, and often useful, to select the same test several times and give it different parameters. When you have supplied the combined test with parameters, the folder with the name Elementary Tests is added under this one. It contains the elementary tests from which the combined test is built. You can delete individual elementary tests in the test pool using drag&drop.
After supplying all tests with parameters, you can start the test run by clicking on the Execution button. After execution, the test icons change from a gray rhombus to a red, yellow or green one, depending on whether the test had errors, warnings or was error-free.
Test Results
The test results are written to the application log. Depending on the settings, the system jumps automatically to this display, or you can reach it by clicking on the Display button. The results are saved in the database, and can therefore be compared later with additional test runs.
In the left-hand side of the window, you can see an overview of the most recent test runs. Double-clicking on a folder displays all messages under these nodes as a flat (non-hierarchical) list in the right-hand screen area. Long texts or detail data may be available for individual messages, which can be displayed with a mouse click.
Repairs
Some tests can repair inconsistencies and errors. Automatic correction is generally not possible: If entries are missing from the SID table for a characteristic, in which case the lost SIDs are still being used in a dimension table (and the corresponding dimension keys are still being used in the fact table) of an InfoCube, you can only remove the inconsistency by reloading the transaction data of the InfoCube. Also note that you must make repairs in the correct sequence. You must always read the documentation for the test and have a good idea about how the error occured, before making the repairs.
After executing the test run, go from the application log back to the initial screen to make these repairs. Click on the Fix Errors button to start an error run. Since the dataset could have changed between the test and the repair run, the required tests are executed again before the actual repair. The results can be found in the application log once again.
After a repair, the test package should be executed again in order to check that the error has been fixed.
Test Packages
The test package is deleted if you do not save the test package in the display before leaving the test environment. Choose Test Package -> Save Test Package from the main menu. You can do the following from options in the Test Package menu:
Load packages; locks are not set for the package; it can only be saved under different names.
Load for processing - the package is then locked against changes by others - and you can save the package again under a different name.
Delete and
Schedule execution at a later date or at regular intervals in background processing.
Note that the execution of test packages can be integrated in process chains. See below for how you do this.
Settings
In the Settings menu option, you can make user-specific settings (adjust the size of the screen areas, for example) and save them. These settings are read automatically when starting the test environment. Additional settings options are being delivered with support packages since the test environment is currently still under development. A message notifies the user at the start if there aren't any values for the setting options.
Jobs Menu Option
You can access the job overview via the Jobs -> Job Overview menu. Use this when you want to check the status of a test package you have scheduled.
Application Log Menu Option
You can display old logs from previous test runs in the dialog box, as well as scheduled ones. The option of deleting test logs can also be found here.
New Selection
The currently selected test package is deleted using the New Selection function (from the memory, though not from the database if the test package had already been saved).
Filter
Use Filter to delete all elementary tests without errors or warnings from the test package after a test run.
Executing Test Packages in Process Chains
In process chain maintenance, transaction RSPC, add your process chain to ABAP program RSRV_JOB_RUNNER. (To do this, in the process type view under General Services, choose the ABAP Program process type by Drag&Drop. When you maintain the process variants, you are asked to specify the program name and a program variant. Enter RSRV_JOB_RUNNER as the name of the program. Choose a program variant name and then Change. On the next screen, you can change or display already existing variants and create new variants. When creating a new variant you are asked to specify the package name (value help is available), the level of detail for the log (to which the RSRV log is to be integrated in the process chain log), and a message type that signifies process chain processing is to be terminated.
The RSRV processes log in the process chain is structured as follows:
It starts with a summary of any errors or warnings that have been produced for each elementary test.
It finishes with a view of the log from the RSRV test package, up to and including the specified level of detail.
Example: If you choose 3 as the level of detail, only messages at levels up to 3 are included in the Process Chain log. Messages produced for a more detailed level of the test package when it is tested are not displayed in this log. Note that, in contrast to the application log, errors are not passed from more to less detailed levels in the process log. For example, if a single error is produced at level 4, the initial summary reports that the test has produceded an error, but this error is not listed in the second part of the log.
A complete log is always written, independently of the log for the RSRV process in the process chain. You can view this log from the menu option Application Log -> Display Log -> From Batch.
Note that there are currently no transport objects for test packages, meaning that these cannot be transported. Process chains that execute RSRV test packages have to be postprocessed manually after being transported into another system: You have to create the corresponding test packages.
on RSRV
Thanks,
JituK

RSRV error - ODS objects !

Hello All,
I'm executing the RSRV test --> Foreign Key Relationship of Reporting-Relevant ODS Object and SID Table Characteristics
and I get the error -
SID values missing for 2 specifications of characteristic 0CALDAY
As i understand some values of 0CALDAY are present in the ODS, but have no corresponding SID's in the SID table.
How is this possible? That there are entries in the ODS but no corresponding SID's in SID table of 0calday.
Please advise !
Thanks in advance.

Hi Abhijit,
One case can be that 'Activate even if no master data exists' option is selected and you have not selected the option for 'SID's generation upon activation'. This makes the ODS not suitable for reporting. Hope this helps.
-Raj

Is there a possibility to run RSRV fix in background?

Hello,
Is there a possibility to schedule/run the "error correction" part of the RSRV result as a background job and not dialog.
Thank you

Hi Blue005,
there is no standard report provided as standard to do the 'Repair' tasks within a BGD job.
The reason for this is that some repairs have to be executed in a certain order or a certain time (when no other jobs can interfere). Furthermore these repairs should be supervised by an administrator.
The system is not supposed to do this automatically.
So you'd have to create your own Z-report making use of report RSRV_JOB_RUNNER (which are the actual RSRV tests) or the function module RSDRD_DIM_REMOVE_UNUSED.
Rgds,
Colum

Can anybody explain me transaction RSRV

Hi,
Please explain me about RSRV
I know it is used for repairing BW OBJECTS
In that we have elementary and combined tests
so kindly explain all the functionalities which r there in elementary and combined tests.
I will assign points.
Thanks in advance,
RAVI ALAKUNTLA

hi ravi,
hi
it's for bw objects consistency analysis and repair.
from transaction code RSRV doc itself :
Transaction RSRV: BW Data and Metadata Test and Repair Environment.
Transaction RSRV checks the consistency of data stored in BW. It mostly examines the foreign key relationships between individual tables in the enhanced star schema of the BW system.
The transaction interface was re-designed for SAP Portals release 3.0A. A brief guide about how to use the transaction follows.
Starting the Transaction
You can reach the test and repair environment
By entering the transaction code RSRV
From InfoObject maintenance (Transaction RSD1)
By clicking on the "Analyze" button in the intial screen.
After selecting a characteristic in the maintenance screen via the "Processing -> Analyze InfoObject" menu option.
The Initial Screen
When using the test and repair environment for the first time, the message "Values were not found for all setting parameters" draws your attention to the fact that there aren't any saved settings for your user.
After confirming the dialog box, you reach the initial screen of the transaction. This is divided into two parts:
1. On the left-hand side, you can see a tree structure with the pool of available tests.
2. The right-hand side is empty at first. The tests you have selected will be put here. A selection of tests is called a Test Package here.
Combined and Elementary Tests
An Elementary Test is a test that cannot be divided into smaller tests and that can therefore only be executed as a whole.
In this regard, a Combined Test determines which elementary tests are to be executed after entering the parameters. You can remove individual elementary tests from the test package before carrying out the actual test run, in order to reduce run time, for example.
Combining a Test Package and Executing it.
Firstly select one or more tests with drag&drop or by double-clicking. Each selected test appears as a closed folder in the view of your test package. (An exception is elementary tests without parameters: These do not appear as a folder). You can also drag a whole folder of tests from the test pool across to the right-hand screen area; all tests that are located in the hierarchical structure under this folder are then added to the test package. You can also display a short description of the test, if required. Do this right-clicking on a test and choosing "Description" from the context menu.
Afterwards, you must supply the tests with parameters. Tests without parameters must not be given parameters. You are given notification of this when selecting them. You can enter parameters by double-clicking on a test (or a test package) or by expanding the folder of the test.
A dialog box appears in which you must enter the required parameters. Input help is often available. After entering the parameters, a folder with the name "Parameter" is added under the test. This contains the parameter values. The test name can change in some circumstances, enabling you to see at first sight for which parameter values the test is to be executed. It is possible to select the same test several times and give it different parameters, which may even be preferable in some situations. When you have supplied the combined test with parameters, the folder with the name "Elementary Tests" is added under this one. It contains the elementary tests, from which the combined test is built. You can delete individual elementary tests in the test pool using drag & drop.
After supplying all tests with parameters, you can start the test run by clicking on the "Execution" button. After execution, the test icons change from a gray rhombus to a red, yellow or green one, depending on whether the test had errors, warnings or was error-free.
Test Results
The test results are written to the application log. Depending on the settings, the system jumps automatically to this display, or you can reach it by clicking on the "Display" button. The results are saved in the database, and can therefore be compared later with additional test runs.
In the left-hand side of the window, you can see an overview of the most recent test runs. Double-clicking on a folder displays all messages under these nodes as a flat (non-hierarchical) list in the right-hand screen area. Long texts or detail data may be available for individual messages, which can be displayed with a mouse click.
Repairs
Some tests can repair inconsistencies and errors. Automatic correction is generally not possible: If entries are missing from the SID table for a characteristic, in which case the lost SIDs are still being used in a dimension table (and the corresponding dimension keys are still being used in the fact table) of an InfoCube, you can only remove the inconsistency by reloading the transaction data of the InfoCube. Also note that you must make repairs in the correct sequence. You must always read the documentation for the test and have a good idea about how the error occured, before making the repairs.
After executing the test run, go from the application log back to the initial screen to make these repairs. Click on the "Fix Errors" button to start an error run. Since the dataset could have changed between the test and the repair run, the required tests are executed again before the actual repair. The results can be found in the application log once again.
Test Packages
The test package is deleted if you do not save the test package in the display before leaving the test environment. Choose "Test Packages -> Save Test Package" in the option menu. You can do the following via options in the "Test Package" menu:
Load packages
Load for processing - the package is then locked against changes by others.
Delete and
Schedule execution at a later date or at regular intervals in background processing
Settings
In the "Settings" menu option, you can make settings (adjust the size of the screen areas, for example) and save them. The settings are automatically read when starting the test environment. Support packages are being delivered with additional settings options since the test environment is under development at the moment. A message notifies the user at the start if there aren't any values for the setting options.
Jobs Menu Option
You can access the job overview via the Jobs -> Job Overview menu. Use this when you want to check the status of a test package you have scheduled.
Application Log Menu Option
You can display old logs from previous test runs in the dialog box, as well as scheduled ones. The option of deleting test logs can also be found here.
New Selection Button
The currently selected test package is deleted when you press this button.
Filter Button
After a test run, click on this button to remove all elementary tests without errors or warnings from the test package.
Executing Test Packages in Process Chains
You can add a process chain to the ABAP Programm RSRV_JOB_RUNNER in the process chain maintenance transaction, RSPC. To do this, use drag & drop to select the process type "ABAP Program" under "General Services" in the process type view. When maintaining process variants you will be asked for the program name and a program variant. Enter RSRV_JOB_RUNNER for the program name. Choose a program variant name and click on "Change". In the next screen you are able to either change or display an already existing variant, or create a new variant. When creating a new variant you will be asked for the following: Package name (an imput help on this is available), the detail level for the log to which the RSRV log in the process chain log is to be integrated, and a message type severity at which process chain processing should be terminated.
The RSRV process log in the process chain is built as follows:
First is a summary specifying whether errors, warnings, or no errors occurred for each elementary test.
A log view of the RSRV test package at the specified detail level follows.
Example: If you choose the value '3' for the detail level, only messages up to and including detail level 3 will be included in the log processes for the process chain. Messages occuring at a lower layer of the test package test are not displayed in this log. Please note that, unlike the application log, the process log does not propagate errors from deep detail levels to low detail levels. For example, if a single detail level 4 error occurs the summary will show that the relevant test delivered an error. However, this error will not be listed in the second part of the log.
A complete log is always written independantly of the RSRV process log in the process chain. You can view this in the menu option "Application Log->Display Log->From Batch".
Please note that there is currently no transport object for test packages and that consequently these cannot be transported. Process chains that execute RSRV test packages must therefore be manually postprocessed after a transport to a different system: The relevant test packages must be created.
hope this helps,
partha

RSRT -- Query Property

Hi all,
is there any way to force Transport request when user change the setting of query property in RSRT.
thanks
cekap

Hi,
RSRT to test and set the properties, if you want to transport you must collect the TR, but RSRT is not the place to collect the TR.
Thanks
Reddy

What r the diff. error that can be solved using RSRV tcode?

Hi ,
what r the diff. error that can be solved using RSRV tcode?
I want to know all the errors that can be solved using RSRV t code
if any body is having good document regarding RSRV please send it to me at
<u><b>[email protected]</b></u>
Thanx in advance,
ravi.

Hi,
Refer the below links for more details about RSRV TCODE.
/community [original link is broken]
http://help.sap.com/saphelp_nw04/helpdata/en/92/1d733b73a8f706e10000000a11402f/frameset.htm
it's for bw objects consistency analysis and repair.
from transaction code RSRV doc itself :
Transaction RSRV: BW Data and Metadata Test and Repair Environment.
Transaction RSRV checks the consistency of data stored in BW. It mostly examines the foreign key relationships between individual tables in the enhanced star schema of the BW system.
The transaction interface was re-designed for SAP Portals release 3.0A. A brief guide about how to use the transaction follows.
Starting the Transaction
You can reach the test and repair environment
By entering the transaction code RSRV
From InfoObject maintenance (Transaction RSD1)
By clicking on the "Analyze" button in the intial screen.
After selecting a characteristic in the maintenance screen via the "Processing -> Analyze InfoObject" menu option.
The Initial Screen
When using the test and repair environment for the first time, the message "Values were not found for all setting parameters" draws your attention to the fact that there aren't any saved settings for your user.
After confirming the dialog box, you reach the initial screen of the transaction. This is divided into two parts:
1. On the left-hand side, you can see a tree structure with the pool of available tests.
2. The right-hand side is empty at first. The tests you have selected will be put here. A selection of tests is called a Test Package here.
Combined and Elementary Tests
An Elementary Test is a test that cannot be divided into smaller tests and that can therefore only be executed as a whole.
In this regard, a Combined Test determines which elementary tests are to be executed after entering the parameters. You can remove individual elementary tests from the test package before carrying out the actual test run, in order to reduce run time, for example.
Combining a Test Package and Executing it.
Firstly select one or more tests with drag&drop or by double-clicking. Each selected test appears as a closed folder in the view of your test package. (An exception is elementary tests without parameters: These do not appear as a folder). You can also drag a whole folder of tests from the test pool across to the right-hand screen area; all tests that are located in the hierarchical structure under this folder are then added to the test package. You can also display a short description of the test, if required. Do this right-clicking on a test and choosing "Description" from the context menu.
Afterwards, you must supply the tests with parameters. Tests without parameters must not be given parameters. You are given notification of this when selecting them. You can enter parameters by double-clicking on a test (or a test package) or by expanding the folder of the test.
A dialog box appears in which you must enter the required parameters. Input help is often available. After entering the parameters, a folder with the name "Parameter" is added under the test. This contains the parameter values. The test name can change in some circumstances, enabling you to see at first sight for which parameter values the test is to be executed. It is possible to select the same test several times and give it different parameters, which may even be preferable in some situations. When you have supplied the combined test with parameters, the folder with the name "Elementary Tests" is added under this one. It contains the elementary tests, from which the combined test is built. You can delete individual elementary tests in the test pool using drag & drop.
After supplying all tests with parameters, you can start the test run by clicking on the "Execution" button. After execution, the test icons change from a gray rhombus to a red, yellow or green one, depending on whether the test had errors, warnings or was error-free.
Test Results
The test results are written to the application log. Depending on the settings, the system jumps automatically to this display, or you can reach it by clicking on the "Display" button. The results are saved in the database, and can therefore be compared later with additional test runs.
In the left-hand side of the window, you can see an overview of the most recent test runs. Double-clicking on a folder displays all messages under these nodes as a flat (non-hierarchical) list in the right-hand screen area. Long texts or detail data may be available for individual messages, which can be displayed with a mouse click.
Repairs
Some tests can repair inconsistencies and errors. Automatic correction is generally not possible: If entries are missing from the SID table for a characteristic, in which case the lost SIDs are still being used in a dimension table (and the corresponding dimension keys are still being used in the fact table) of an InfoCube, you can only remove the inconsistency by reloading the transaction data of the InfoCube. Also note that you must make repairs in the correct sequence. You must always read the documentation for the test and have a good idea about how the error occured, before making the repairs.
After executing the test run, go from the application log back to the initial screen to make these repairs. Click on the "Fix Errors" button to start an error run. Since the dataset could have changed between the test and the repair run, the required tests are executed again before the actual repair. The results can be found in the application log once again.
Test Packages
The test package is deleted if you do not save the test package in the display before leaving the test environment. Choose "Test Packages -> Save Test Package" in the option menu. You can do the following via options in the "Test Package" menu:
Load packages
Load for processing - the package is then locked against changes by others.
Delete and
Schedule execution at a later date or at regular intervals in background processing
Settings
In the "Settings" menu option, you can make settings (adjust the size of the screen areas, for example) and save them. The settings are automatically read when starting the test environment. Support packages are being delivered with additional settings options since the test environment is under development at the moment. A message notifies the user at the start if there aren't any values for the setting options.
Jobs Menu Option
You can access the job overview via the Jobs -> Job Overview menu. Use this when you want to check the status of a test package you have scheduled.
Application Log Menu Option
You can display old logs from previous test runs in the dialog box, as well as scheduled ones. The option of deleting test logs can also be found here.
New Selection Button
The currently selected test package is deleted when you press this button.
Filter Button
After a test run, click on this button to remove all elementary tests without errors or warnings from the test package.
Executing Test Packages in Process Chains
You can add a process chain to the ABAP Programm RSRV_JOB_RUNNER in the process chain maintenance transaction, RSPC. To do this, use drag & drop to select the process type "ABAP Program" under "General Services" in the process type view. When maintaining process variants you will be asked for the program name and a program variant. Enter RSRV_JOB_RUNNER for the program name. Choose a program variant name and click on "Change". In the next screen you are able to either change or display an already existing variant, or create a new variant. When creating a new variant you will be asked for the following: Package name (an imput help on this is available), the detail level for the log to which the RSRV log in the process chain log is to be integrated, and a message type severity at which process chain processing should be terminated.
The RSRV process log in the process chain is built as follows:
First is a summary specifying whether errors, warnings, or no errors occurred for each elementary test.
A log view of the RSRV test package at the specified detail level follows.
Example: If you choose the value '3' for the detail level, only messages up to and including detail level 3 will be included in the log processes for the process chain. Messages occuring at a lower layer of the test package test are not displayed in this log. Please note that, unlike the application log, the process log does not propagate errors from deep detail levels to low detail levels. For example, if a single detail level 4 error occurs the summary will show that the relevant test delivered an error. However, this error will not be listed in the second part of the log.
A complete log is always written independantly of the RSRV process log in the process chain. You can view this in the menu option "Application Log->Display Log->From Batch".
Please note that there is currently no transport object for test packages and that consequently these cannot be transported. Process chains that execute RSRV test packages must therefore be manually postprocessed after a transport to a different system: The relevant test packages must be created.
Hope This Helps,
This is already there in SDN.
Regards,
rik

RSRV Error

I ran the RSRV test for the "Database Information about InfoProvider Tables" to check the Fact Table/Dimension table entries and their percentages with respect to fact table.
But the test did not return the intended results. I had about 25 records in the Infocube. i ran the test and got the results. no problem. After that, I loaded another 30000 odd records. If I run the RSRV test now, its still showing 25 records. but by doing SE16 of all the tables, I see the correct numbers.
I deleted all the requests from the Infocube, loaded it again multiple times... Still the same problem. I refreshed InfoCube statistics. I modified the infocube by adding another characteristc, reactivated it, loaded data, refreshed stats. still the same problem... still its showing 25 records...
I assume its the buffer problem in my system, but has anyone else experienced it?
I havn't tested with other cubes.
Thanks
Gova

As Bhanu mentions, the row counts are based on the DB statistics rather than the actual row counts in the fact cube and dimension tables.
You always need to refresh table statistics after you have loaded a lot of data to an empty or nearly empty InfoProvider. It's possible that depending on how DB statistics are collected on your system, they would have automatically been updated overnight. Might want to verify with your DB how they handle statistics collection - it can vary from shop to shop.
The same results would be true with the SAP_INFOCUBE_DESGINS program if you ran than rathrer than RSRV.
You can refresh the statistics immediately after a load form the Manage tab.

Possible to test aggregates via web template?

Hi,
Is there i similar transaction code to rsrt to test web templates (instead of queries), for aggregates?
We have a web template with several data providers and queries, and it would be a lot easier to test via the template.
BR,
Niclas

Hi,
after switching to html display you see a large box. Just add &template_id=<your templayte name>. The query field can be empty.
It only works for webtemplates created with WAD 3.5 however.
Best regards,
Ralf

RSRV t-code

what is RSRV Transaction code

Hello narasimha42 raja ,
RSRV: BI Data and Metadata Test and Repair Environment.
RSRV checks the consistency of data stored in BI. It mostly examines the foreign key relationships between individual tables in the enhanced star schema of the BI system.
The Initial Screen
When using the test and repair environment for the first time, the message "Values were not found for all setting parameters" draws your attention to the fact that there are not any saved settings for your user.
After confirming the dialog box, you reach the initial screen of the transaction. This is divided into two parts:
1. On the left-hand side, you can see a tree structure with the pool of available tests.
2. The right-hand side is empty at first. The tests you have selected will be put here. A selection of tests is called a Test Package here.
Combined and Elementary Tests
An Elementary Test is a test that cannot be divided into smaller tests and can therefore only be executed as a whole (or not at all).
In this regard, a Combined Test determines which elementary tests are to be executed after entering the parameters. You can remove individual elementary tests from the test package before carrying out the actual test run, in order to reduce run time, for example.
Combining a Test Package and Executing it.
Firstly select one or more tests with drag&drop or by double-clicking. Each selected test appears as a closed folder in the view of your test package. (An exception is elementary tests without parameters: These do not appear as a folder). You can also drag a whole folder of tests from the test pool across to the right-hand screen area; all tests that are located in the hierarchical structure under this folder are then added to the test package. You can also display a short description of the test, if required. Do this right-clicking on a test and choosing "Description" from the context menu.
Afterwards, you must supply the tests with parameters. Tests without parameters must not be given parameters. You are given notification of this when selecting them. You can enter parameters by double-clicking on a test (test package) or by opening a test folder.
A popup appears in which you have to enter the required parameter values. Often, there is value help available. After the parameters are entered, a folder with the name Parameter is added under the test. This contains the parameter values. The test name can change in some circumstances, enabling you to see at first glance for which parameter values the test is to be executed. It is possible, and often useful, to select the same test several times and give it different parameters. When you have supplied the combined test with parameters, the folder with the name Elementary Tests is added under this one. It contains the elementary tests from which the combined test is built. You can delete individual elementary tests in the test pool using drag&drop.
After supplying all tests with parameters, you can start the test run by clicking on the Execution button. After execution, the test icons change from a gray rhombus to a red, yellow or green one, depending on whether the test had errors, warnings or was error-free.
Test Results
The test results are written to the application log. Depending on the settings, the system jumps automatically to this display, or you can reach it by clicking on the Display button. The results are saved in the database, and can therefore be compared later with additional test runs.
In the left-hand side of the window, you can see an overview of the most recent test runs. Double-clicking on a folder displays all messages under these nodes as a flat (non-hierarchical) list in the right-hand screen area. Long texts or detail data may be available for individual messages, which can be displayed with a mouse click.
Repairs
Some tests can repair inconsistencies and errors. Automatic correction is generally not possible: If entries are missing from the SID table for a characteristic, in which case the lost SIDs are still being used in a dimension table (and the corresponding dimension keys are still being used in the fact table) of an InfoCube, you can only remove the inconsistency by reloading the transaction data of the InfoCube. Also note that you must make repairs in the correct sequence. You must always read the documentation for the test and have a good idea about how the error occured, before making the repairs.
After executing the test run, go from the application log back to the initial screen to make these repairs. Click on the Fix Errors button to start an error run. Since the dataset could have changed between the test and the repair run, the required tests are executed again before the actual repair. The results can be found in the application log once again.
After a repair, the test package should be executed again in order to check that the error has been fixed.
Test Packages
The test package is deleted if you do not save the test package in the display before leaving the test environment. Choose Test Package -> Save Test Package from the main menu. You can do the following from options in the Test Package menu:
Load packages; locks are not set for the package; it can only be saved under different names.
Load for processing - the package is then locked against changes by others - and you can save the package again under a different name.
Delete and
Schedule execution at a later date or at regular intervals in background processing.
Note that the execution of test packages can be integrated in process chains. See below for how you do this.
Settings
In the Settings menu option, you can make user-specific settings (adjust the size of the screen areas, for example) and save them. These settings are read automatically when starting the test environment. Additional settings options are being delivered with support packages since the test environment is currently still under development. A message notifies the user at the start if there aren't any values for the setting options.
Jobs Menu Option
You can access the job overview via the Jobs -> Job Overview menu. Use this when you want to check the status of a test package you have scheduled.
Application Log Menu Option
You can display old logs from previous test runs in the dialog box, as well as scheduled ones. The option of deleting test logs can also be found here.
New Selection
The currently selected test package is deleted using the New Selection function (from the memory, though not from the database if the test package had already been saved).
Filter
Use Filter to delete all elementary tests without errors or warnings from the test package after a test run.
Executing Test Packages in Process Chains
In process chain maintenance, transaction RSPC, add your process chain to ABAP program RSRV_JOB_RUNNER. (To do this, in the process type view under General Services, choose the ABAP Program process type by Drag&Drop. When you maintain the process variants, you are asked to specify the program name and a program variant. Enter RSRV_JOB_RUNNER as the name of the program. Choose a program variant name and then Change. On the next screen, you can change or display already existing variants and create new variants. When creating a new variant you are asked to specify the package name (value help is available), the level of detail for the log (to which the RSRV log is to be integrated in the process chain log), and a message type that signifies process chain processing is to be terminated.
The RSRV processes log in the process chain is structured as follows:
It starts with a summary of any errors or warnings that have been produced for each elementary test.
It finishes with a view of the log from the RSRV test package, up to and including the specified level of detail.
Example: If you choose 3 as the level of detail, only messages at levels up to 3 are included in the Process Chain log. Messages produced for a more detailed level of the test package when it is tested are not displayed in this log. Note that, in contrast to the application log, errors are not passed from more to less detailed levels in the process log. For example, if a single error is produced at level 4, the initial summary reports that the test has produceded an error, but this error is not listed in the second part of the log.
A complete log is always written, independently of the log for the RSRV process in the process chain. You can view this log from the menu option Application Log -> Display Log -> From Batch.
Note that there are currently no transport objects for test packages, meaning that these cannot be transported. Process chains that execute RSRV test packages have to be postprocessed manually after being transported into another system: You have to create the corresponding test packages.
With Warm Regards,
Vineeth

Regarding RSRV transaction

hia
can anyone tell , when we have to use RSRV transaction and what are the precautions we have to take to use this transaction . please tell me ...
Any weblog or documentation . please tell me ....
Thanks
bye

hi
it's for bw objects consistency analysis and repair.
from transaction code RSRV doc itself :
Transaction RSRV: BW Data and Metadata Test and Repair Environment.
Transaction RSRV checks the consistency of data stored in BW. It mostly examines the foreign key relationships between individual tables in the enhanced star schema of the BW system.
The transaction interface was re-designed for SAP Portals release 3.0A. A brief guide about how to use the transaction follows.
Starting the Transaction
You can reach the test and repair environment
By entering the transaction code RSRV
From InfoObject maintenance (Transaction RSD1)
By clicking on the "Analyze" button in the intial screen.
After selecting a characteristic in the maintenance screen via the "Processing -> Analyze InfoObject" menu option.
The Initial Screen
When using the test and repair environment for the first time, the message "Values were not found for all setting parameters" draws your attention to the fact that there aren't any saved settings for your user.
After confirming the dialog box, you reach the initial screen of the transaction. This is divided into two parts:
1. On the left-hand side, you can see a tree structure with the pool of available tests.
2. The right-hand side is empty at first. The tests you have selected will be put here. A selection of tests is called a Test Package here.
Combined and Elementary Tests
An Elementary Test is a test that cannot be divided into smaller tests and that can therefore only be executed as a whole.
In this regard, a Combined Test determines which elementary tests are to be executed after entering the parameters. You can remove individual elementary tests from the test package before carrying out the actual test run, in order to reduce run time, for example.
Combining a Test Package and Executing it.
Firstly select one or more tests with drag&drop or by double-clicking. Each selected test appears as a closed folder in the view of your test package. (An exception is elementary tests without parameters: These do not appear as a folder). You can also drag a whole folder of tests from the test pool across to the right-hand screen area; all tests that are located in the hierarchical structure under this folder are then added to the test package. You can also display a short description of the test, if required. Do this right-clicking on a test and choosing "Description" from the context menu.
Afterwards, you must supply the tests with parameters. Tests without parameters must not be given parameters. You are given notification of this when selecting them. You can enter parameters by double-clicking on a test (or a test package) or by expanding the folder of the test.
A dialog box appears in which you must enter the required parameters. Input help is often available. After entering the parameters, a folder with the name "Parameter" is added under the test. This contains the parameter values. The test name can change in some circumstances, enabling you to see at first sight for which parameter values the test is to be executed. It is possible to select the same test several times and give it different parameters, which may even be preferable in some situations. When you have supplied the combined test with parameters, the folder with the name "Elementary Tests" is added under this one. It contains the elementary tests, from which the combined test is built. You can delete individual elementary tests in the test pool using drag & drop.
After supplying all tests with parameters, you can start the test run by clicking on the "Execution" button. After execution, the test icons change from a gray rhombus to a red, yellow or green one, depending on whether the test had errors, warnings or was error-free.
Test Results
The test results are written to the application log. Depending on the settings, the system jumps automatically to this display, or you can reach it by clicking on the "Display" button. The results are saved in the database, and can therefore be compared later with additional test runs.
In the left-hand side of the window, you can see an overview of the most recent test runs. Double-clicking on a folder displays all messages under these nodes as a flat (non-hierarchical) list in the right-hand screen area. Long texts or detail data may be available for individual messages, which can be displayed with a mouse click.
Repairs
Some tests can repair inconsistencies and errors. Automatic correction is generally not possible: If entries are missing from the SID table for a characteristic, in which case the lost SIDs are still being used in a dimension table (and the corresponding dimension keys are still being used in the fact table) of an InfoCube, you can only remove the inconsistency by reloading the transaction data of the InfoCube. Also note that you must make repairs in the correct sequence. You must always read the documentation for the test and have a good idea about how the error occured, before making the repairs.
After executing the test run, go from the application log back to the initial screen to make these repairs. Click on the "Fix Errors" button to start an error run. Since the dataset could have changed between the test and the repair run, the required tests are executed again before the actual repair. The results can be found in the application log once again.
Test Packages
The test package is deleted if you do not save the test package in the display before leaving the test environment. Choose "Test Packages -> Save Test Package" in the option menu. You can do the following via options in the "Test Package" menu:
Load packages
Load for processing - the package is then locked against changes by others.
Delete and
Schedule execution at a later date or at regular intervals in background processing
Settings
In the "Settings" menu option, you can make settings (adjust the size of the screen areas, for example) and save them. The settings are automatically read when starting the test environment. Support packages are being delivered with additional settings options since the test environment is under development at the moment. A message notifies the user at the start if there aren't any values for the setting options.
Jobs Menu Option
You can access the job overview via the Jobs -> Job Overview menu. Use this when you want to check the status of a test package you have scheduled.
Application Log Menu Option
You can display old logs from previous test runs in the dialog box, as well as scheduled ones. The option of deleting test logs can also be found here.
New Selection Button
The currently selected test package is deleted when you press this button.
Filter Button
After a test run, click on this button to remove all elementary tests without errors or warnings from the test package.
Executing Test Packages in Process Chains
You can add a process chain to the ABAP Programm RSRV_JOB_RUNNER in the process chain maintenance transaction, RSPC. To do this, use drag & drop to select the process type "ABAP Program" under "General Services" in the process type view. When maintaining process variants you will be asked for the program name and a program variant. Enter RSRV_JOB_RUNNER for the program name. Choose a program variant name and click on "Change". In the next screen you are able to either change or display an already existing variant, or create a new variant. When creating a new variant you will be asked for the following: Package name (an imput help on this is available), the detail level for the log to which the RSRV log in the process chain log is to be integrated, and a message type severity at which process chain processing should be terminated.
The RSRV process log in the process chain is built as follows:
First is a summary specifying whether errors, warnings, or no errors occurred for each elementary test.
A log view of the RSRV test package at the specified detail level follows.
Example: If you choose the value '3' for the detail level, only messages up to and including detail level 3 will be included in the log processes for the process chain. Messages occuring at a lower layer of the test package test are not displayed in this log. Please note that, unlike the application log, the process log does not propagate errors from deep detail levels to low detail levels. For example, if a single detail level 4 error occurs the summary will show that the relevant test delivered an error. However, this error will not be listed in the second part of the log.
A complete log is always written independantly of the RSRV process log in the process chain. You can view this in the menu option "Application Log->Display Log->From Batch".
Please note that there is currently no transport object for test packages and that consequently these cannot be transported. Process chains that execute RSRV test packages must therefore be manually postprocessed after a transport to a different system: The relevant test packages must be created.

RSRT, RSRV Testing

Similar Messages

Maybe you are looking for