We have added search box. Key in SAP issue keyword to search
TopBottom

Announcement: wanna exchange links? contact me at sapchatroom@gmail.com.
Showing posts with label Types. Show all posts
Showing posts with label Types. Show all posts

Basis Display Types and Views of the Alert Monitor

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Purpose

The Alert Monitor provides two system views (Current Status and Open Alerts), with which you can display the status of your monitored systems. In addition, there are also the display types Alert Browser and Detail Data for displaying more detailed information about open alerts or selected monitoring tree elements (MTEs).

Current Status

This system view displays the current data for every MTE. When you begin to check the system, you begin with this view:

Caution

Heartbeat alerts are not displayed in this view (see Triggering a Heartbeat Alert if no Values Are Reported).

This graphic is explained in the accompanying text

Open Alerts

The following image shows the Open Alerts view. This view shows where alerts exist that have not yet been analyzed and set to complete. The color indicator for alerts is set in accordance with the most serious alert that has not yet been processed. Switch to this view to see whether problems have occurred since the last time you used the Alert Monitor.

Caution

This view does not necessarily correspond to the current status of the system.

This graphic is explained in the accompanying text

Alert Browser

A third display type is the Alert Browser, which you start through the Alert Monitor. The Alert Browser displays a list of the open alerts in a flat hierarchy. To do this, select the MTEs for which you want to display the alerts that have not yet been completed. The Alert Browser tool is therefore well suited to systematically processing all alerts that have not yet been completed.

Technical Views

The Technical Viewsshould be considered separately from the above display types. In technical views, the displayed information is not current values or alerts for nodes, but rather information about properties and methods of the nodes. You can also display this information for individual nodes by choosing the Properties pushbutton, however you can see the relevant information for all nodes of a monitor in the technical views. There are the following technical views:

· Technical View: Info on MTE

· Technical View: Method Allocation

· Technical View: Status Data Collector

· Technical View: Status Autoreaction

· Displaying the Technical View: Threshold Values

· Technical View: Central Performance History

Displaying Detail Data

You can display the detail data for one or more MTEs from both system views of the Alert Monitor. The display of the detail data shows you:

· The most serious alert that has not yet been processed (if one exists)

· For performance attributes, the current performance data, the associated alert threshold values and the combined, smoothed data for the last 30 minutes and 24 hours

· For status and log attributes, the last message

· The general properties of the selected MTEs



Keyword: BASIS
Title : Basis Display Types and Views of the Alert Monitor

SAP Lock Types

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Keyword: BASIS
Title : SAP Lock Types

Labels: , ,

SAP Workload Analysis: Average Usage of All Memory Types (KB)

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

SAP Workload Analysis: Average Usage of All Memory Types (KB)

The average memory usage is calculated by dividing the total memory usage by the number of associated dialog steps.

The total memory usage is made up of the components roll memory, extended memory and heap memory. Work processes use memory in the following order:

Roll Memory to the limit set by ztta/roll_first

Extended memory to limit set by ztta/roll_extension or until there is no more space available in extended memory.

Roll Memory: rest of the space in the roll area until ztta/roll_area.

Heap Memory until abap/heap_area_dia is reached or all space in heap memory is used.

For non-dialog work processes, there used to be an allocation order.



Keyword: BASIS
Title : SAP Workload Analysis: Average Usage of All Memory Types (KB)

ABAP dictionary object types

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Keyword: BASIS
Title : ABAP dictionary object types

R/3 Memory Types SAP

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Definition

The memory management system assigns memory to a work process. There are the following memory types:


  • R/3 Roll Area

  • R/3 Extended Memory

  • Private Memory

To find out the order in which memory type is assigned, refer to Allocating Memory for User Contexts.

The area of a user context that is directly accessible is now extended as needed, if the user context has expanded.

Use

For dialog work processes, the data of the user context, including internal tables is located in this Extened Memory. You can therefore access all the data in the user context directly. The data types Extract and Export to Memory remain in the SAP Paging.

The roll area is used for the initial memory assigned to a user context, and (if available) for additional memory if the Extened Memory is full.

The majority of the user context is stored in the Extended Memory. Page management of this memory as a stack is not taken from the operating system; rather it is performed directly from the R/3 System. This Extended Memory is implemented as an unnamed mapped file (on AIX and optionally on HP-UX as shared memory). This means the address space uses the paging file or uses the swap space of the operating system as background memory. For more information, refer to the man page mmap (UNIX systems), or Create File Mapping and Map View of File for Microsoft Windows NT.

With the context change, the user context is not copied as with the roll area. Instead it is assigned to alternating work processes by mapping operations. The roll area can be decreased, which results in a faster context change because less data is copied and mapping an extended area is not work-intensive.

All internal tables and ABAP variables are located completely in the area of a user context that can be directly addressed. Copying and in/output operations when accessing internal tables and lists is no longer needed. The result is low CPU usage and shorter access times.

The advantages of the memory management system require increased swap space and main memory. The need for swap space increases because the internal tables and lists now are in the address space in their full size requiring swap space. The main memory requirements may increase to prevent excessive operating system paging due to the increased swap space requirements.



Keyword: BASIS
Title : R/3 Memory Types SAP

Labels: , ,

Types of tables are there in R/3 Database

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Client-Dependent and Client-Independent.

A table is client-dependent if the first table field type is of type CLNT. The length will always be 3. And this field is always named ‘MANDT’.

If the first is not of type CLNT the table is Client-Independent



Keyword: BASIS
Title : Types of tables are there in R/3 Database

SAP Memory Types

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Keyword: BASIS
Title : SAP Memory Types

Labels: , ,

SAP Memory Types :: Extended Memory

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Keyword: BASIS
Title : SAP Memory Types :: Extended Memory

SAP Memory Types : Private Memory

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Keyword: BASIS
Title : SAP Memory Types : Private Memory

Types of Buffer

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit


NTAB buffer:


The name table (nametab) contains the table and field definitions that are activated in the SAP System. An entry is made in the Repository buffer when a mass activator or a user (using the ABAP Dictionary, Transaction SE11) requests to activate a table. The corresponding name table is then generated from the information that is managed in the Repository.

The Repository buffer is mainly known as the nametab buffer (NTAB), but it is also known as the ABAP Dictionary buffer.

Table definitions: TTAB

Field descriptions: FTAB

Initial record layouts: IREC Buffer (Contains the record layout initialized depending on the field type)

Short Nametab: SNTAB Buffer (A short summary of TTAB and FTAB buffers)

The description of a table in the Repository is distributed among several tables (for field definition, data element definition and domain definition). This information is summarized in the name table. The name table is saved in the following database tables:

DDNTT (table definitions)
DDNTF (field descriptions)

The Repository buffer consists of four buffers in shared memory, one for each of the following
The Short nametab and Initial record layouts are not saved in the database. Instead, they are derived from the contents of tables DDNTT and DDNTF.

When access to a table is requested, the database access agent embedded in each work process first reads the Short nametab buffer for information about the table. If the information is insufficient (for example, the SELECT statement uses a non-primary key) it accesses the Table definitions buffer and then the Field descriptions buffer.

By reading the Repository buffers, the database access agent knows whether the table is buffered or not. Using this information, it accesses the table buffers (partial buffer or generic buffer) or the database

Program buffer: Also called as
SAP executable buffer
ABAP buffer
PXA (Program Execution Area)

Stores the compiled executable versions of ABAP programs (loads).

The contents of this buffer are stored in tables D010L (ABAP loads), D010T (texts) and D010Y (symbol table)

Calender Buffer:
The SAP calendar buffer stores all defined factory and public holiday calendars.
Calendars are stored in the database tables TFACS and THOCS.

There are two kinds of SAPgui buffers
:
Presentation buffers
Menu buffers
The following table shows the SAPgui buffers and their functions:

The buffer has a directory structure. This means that if the shared memory is configured too small, only the required data is loaded; there is no LRU displacement of the contents of the buffer.
Presentation buffer (Screen Buffer): Stores the generated screens (DYNPRO loads)
Menu buffer (CUA Buffer): Stores objects from the SAPgui.

For example, menus, pushbutton definitions.
The buffer has directory structure and supports LRU displacement.
The menu buffer is adjusted by amending its instance profile parameters

The CUA buffer holds objects from the GUI interface, such as menus, pushbuttons, and so on. In the database, these objects are held in tables D342L and D345T. Its size is expressed in KB. The standard SAP recommendation is: Up to 2500 KB for small systems, up to 3000 KB for medium systems and up to 6000 KB for large systems.



Keyword: BASIS
Title : Types of Buffer

Labels: , ,

SAP Memory Types :: Roll Area

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Keyword: BASIS
Title : SAP Memory Types :: Roll Area

SAP User Types

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Keyword: BASIS
Title : SAP User Types

Labels: , ,

Data Structure and Data Types of an R/3 System

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Keyword: BASIS
Title : Data Structure and Data Types of an R/3 System

Transport types

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

The transport types:

K type: The system owner does not get changed with K type transport. This kind of transport is only allowed to consolidation and production system. After the K type of transport is done no correction is allowed to those objects. Any changes to K type transport objects in consolidation system are called repair.
The repairs can be done to those objects if the change option is selected in SE06 and change option is there in client level selection in T00 table. Generally K type transport is used for stage and production environment.

C type: With the C type transport the ownership of that object is also transferred to the target. After the transport is done, the target system is the owner of the transported objects. The objects will be originals of the target system. These kind of transports are generally done in a four tier architecture, where a bundle of development objects can go from the sandbox environment to development environment or development environment to integration environment and vice versa. SAP recommends doing these transports when the objects should move to another system for further development work.

T type: T type is called a transport of copy. The ownership of the object remains with the source; the target system just gets the copy of the objects. When a sap patch is applied to the development system and transported to other systems, those are perfect example of T type transports.



Keyword: BASIS
Title : Transport types

Types of RFC (Remote Function Calls)

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

Types of RFC

Synchronous RFC (sRFC)
For communication between different systems and between SAP Web AS and SAP GUI.

Asynchronous RFC (aRFC)
For communication between different systems and for parallel processing of selected tasks.

Transactional RFC (tRFC)
A special form of asynchronous RFC. Transactional RFC ensures transaction-like processing of processing steps that were originally autonomous.

Queue(d) RFC (qRFC)
Queued RFC is an extension of tRFC. It also ensures that individual steps are processed in sequence.

RFC is a superordinate term for various implementation variants. sRFC is the synchronous call of function modules. This means that the client waits until the server has completed its processing. In an SAP system, an RFC can also be performed asynchronously in another work process. This variant is called aRFC.

There is also tRFC, the transactional Remote Function Call. Transactional RFC is asynchronous and ensures that data that is sent more than once due to network problems, can be recognized at the server side, by assigning a Transaction Identifier (TID). This allows you to prevent data being processed more than once, leading to erroneous information in the application. Due to the asynchronous processing, however, parameters can only be transferred from the client to the server in this case. Returning information or status information directly is not possible.

qRFC with Send Queue is an extension of tRFC. It creates a layer between applications and the tRFC and only allows the tRFC to transfer a Logical Unit of Work (LUW) to the target server when its predecessors are no longer in the associated wait queues. After a qRFC LUW is executed, the qRFC manager automatically processes the next waiting qRFC LUW in accordance with the sequence in the wait queue.


Keyword: BASIS
Title : Types of RFC (Remote Function Calls)

Types of Change Requests

Posted by Admin at
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit

There are two main types or categories of change requests, SYST and CUST.

SYST changes record a version of the ABAP Objects and general customizing object
when the request is released. These changes also lock all the objects in the request, which prevents users from making changes to the objects from the time of change until the release of the request.

CUST requests are comprised of client-dependent customizing changes. Each object of a
CUST request contains a table key. The key has the client, where the data are stored; the table name, where the data are stored; and the key, which defines what rows of the table are stored in the request. CUST changes do not lock the objects (table rows) at anytime.So it's important that access to customizing changes is controlled properly.



Keyword: BASIS
Title : Types of Change Requests

T r a n s l a t e to your language