GIVE ME DETAILS FUNCTION ON T CODE RSRV DETAILS

Question

GIVE ME DETAILS FUNCTION ON T CODE RSRV  DETAILS

Answer 1

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