ISUSER (INDIAN SAP USER FORUM) ASUSER(AMERICAN SAP USER FORUM)
Communicate with SAP vendor (Channel Partners) and purchase the license.
License is a single user based. i.e. If we buy one license we can access ... ERP, SRM, BI, PI, EP, Solution Manager, MI etc.)
SCM. SRM CRM are charged Separately.
If we buy MYSAP business suite then all comes under one license.
* There is no lock for licensed users in the system. We can buy 100 Users and used for 10,000 Users. * Every year we need to run USMM and send the report to SAP.
License Cost varies based on Geographical Location MySAPFI - Oracle Apps
MySAPSCM - Peoplesoft MySAPCRM - Sieble Each license cost 2000 USD Each Developer Cost 4000 USD
After negotiation in Indian Market the Single user cost comes to 40,000 to 1,00,000 depending upon number of users.
For 40,000 we should have atleast 150-200 Users for 10+1 cost 18 Lakhs. ---
Note:
Heap Memory - Part of the Physical Memory (RAM Memory) Physical Memory - RAM
Virtual Memory - Part of the Memory from the Hard disk Buffer
Bin - Points to the target system BIN contains default.pfl
SAP_BC_ADMIn S_Transports CTS_Admin
Disp+exe ( PING, Etc Entry, Any Kernel upgrade has been done (DEV_DISP.log) ---
BASIS
- It provides runtime environment for SAP Applications. - 2.0 is based on two tier which is built on Mainframes.
- 3.0 onwards and upto 3.1I it is based on three tier and web services are provided by using ITS. - 4.0; 4.5A, 4.5B
- 4.6 A, B, C and D is kernel versions
(Mining, Textile, Chemical, Oil, Utilities, Real Estates, baking, Insurance... etc.)
SAP determined to bring all the components on to a common platform and introduced SAP Web Application Server (WAS)
The first version of WAS is 620 (A direct jump from 4.6D) On 620 ... ERP Version is 4.7E
On 620 ...BW version is 3.1C Owner of the Database
- SAPSR3... Upto BASIS 4.6C
4.6D is the Kernel Version. - SAP<SID> ... from WEBAS 620 to 640
It provides built in ITS to make application server as WEB Application Server. - SAPSR3 from WEBAS 700
It is a Netweaver (640... 700...710). Next Level of WAS is 640
ERP - ECC 5.0 BW - 3.5 SCM - 4.0 CRM - 4.0
2.0, 3.0, 3.1 are BW Versions 2.0, 3.0, APO are SCM Versions 2.0, 3.0, SRM are SRM Versions XI - 3.0
Next level of WAS is 700 ERP - ECC6.0 BW - BI7.0 EP - EP7.0 XI - PI7.0 SRM - 5.0 CRM - 5.0
Install ABAP(CI, DBI), JAVA add on. Install Central System Installation (Select Usage type during Installation)
R/3 Setup is used to install SAP upto Versions Basis 4.6C
SAPINST introduced in WEB Application Server 620-640. Interactive SAPINST is to modify the inputs move front and back to review the inputs introduced in WAS700.
BASIS only Non-Unicode
From SAPWEBAS 640 unicode is introduced.
Run directory is used to host executables of kernel upto 640 where as OS version (NTI386, AMD64, IA64) with UC/ NUC is available in version 700.
OLD: The database table spaces are 27 which ends with D(Data) and I(Index)..[SAPR3] owner. From 620
The database contains only 6 tablespaces(Physical Location) in 640 owner is SAP<SID> PSAP<SID> PSAP<SID>USR PSAP<SID>REL SYSTEM PSAPROLL(PSAPUNDO) PSAPTEMP
SQL> Select tablespace_name from dba_tablespaces.
The database contains only 8 tablespaces in 700. Owner is SAPSR3 for ABAP engine and SAPSR3DB is for JAVA Engine.
SYSTEM - Database Related PSAPUNDO - For Roll Back
PSAPTEMP - Temp Storage Memory PSAPSR3 - Component Specific PSAPSR3700 - Version Specific PSAPSR3USR - USER RELATED Info PSAPSR3DB - JAVA Specific DB
GUI Versions 46C 46D 620 640 700 710
Based on Windows and JAVA
SQL> select username from DBA_USERS;
Database Users (DDIC and SAP* are SAP Users resides in USR02 Table) SQL> select count(*) from DBA_USERS where owner = 'SAPSR3';
17476
SQL> select count(*) from SAPSR3.DD02L; 65611
SQL> select count(*) , owner from DBA_USERS group by owner; Eg. [CDCLS] Cluster Table.
The difference is because of --
19,xxx 65xxx
Components: BASIS BASIS+ERP
31-Aug-09 DATABASE
We can also store the data in terms of file system like test.txt, test.pdf, test.doc, test.rtf, test.xls, test.ppt, test.pps
Disadvantage of the file system
1. The data is not in the organized format. 2. There are no indexes to search the data.
3. The data does not follow the LUW concept and so it is not consistent and reliable.
4. The version management will be difficult and time consuming to get the required/ identify the file. 5. The backup management and reorganization is not available.
These are the reasons for the evolution of DB.
Database: Used to store the data in the organized format and it has to follow RDBMS rules (Relational Database Management System)
- Data is stored in terms of tables (Tables contain rows and columns). Columns are headers and rows are the data.
- Duplication of data is avoided and uniqueness is obtained by using primary and secondary keys.
- Data search is faster by using indexes (based on Keys)
Eg: As in windows we can create as many folders and subfolders with the same name and the search criteria depends on the search string.
C:\shawn\shawn\shawn...
- Database has its own structure to manage the data using the database specific binaries and libraries. Oracle/bin; mssql/bin; db2/bin;
Oracle/lib; mssql/lib; db2/lib;
- Database provides tools for backup management, reorganization, restore and recovery - Databases follow RDBMS rules to achieve consistency, reliability and transaction LUW. LUW - LOGIC UNIT OF WORK.
It consists of one or more transactions that are bundled together which can be committed as a group or rollback without any data loss.
RFQ(Approved) - Sales Order
Purchase Req - FI Dept (Approval) - Purchase Order - Tenders (Contractors)
(Eg: Purchase Order, Sales Order, Invoice, GR(Goods Receipt), GI (Goods Issued) AP (Account Payables), AR (Account Receivables)
- Data is normalized and denormalised according to the requirements of the customer. NORMALIZATION
Process of splitting up the larger tables into smaller tables using primary keys and secondary keys... ERP(ECC6), SRM.
Databases are normalized. DENORMALIZATION
Process of grouping smaller tables into larger tables for having data comprehensively available for analysis and reporting BIW.
[SELECT, INSERT, UPDATE, MODIFY, DELETE] Scenario
User requests for weekly status report. 1. User submits the request.
2. Request is handled by dispatcher 3. Keeps the request in Queue
4. Based on the available processes requests are served based on FIFO.
5. R/3 Work process handles the user request by interpreting the screen elements, program logic (Insert, Modify, Delete, Update)
6. The response is fetched from buffers if they are accessed earlier
7. If the request is not accessed earlier, the request is converted into Native SQL statements of the respective database.
8. R/3 Work process communicates with database process to get the response.
9. Database work process checks whether the table exists, if table exists then checks for the fields, if the field and table exists, then asks for the optimized path to go to the database table and identify the relevant rows based on keys/ Indexes (Five 5 Seconday Indexes)
10. The data is fetched into Database buffers before the response is sent to R/3 work process. 11. R/3 Work process keeps a copy in the R/3 Buffer and response is sent to user.
01-Sep-09 UPDATE COMMAND
1. User request for updating a purchase order/ quotation / Invoice 2. The request is received by the dispatcher
3. Dispatcher keeps the request in queue based on FIFO
4. R/3 Work process handles the request and update the document into temporary tables (cannot update the permanent tables because all the LUW's in the transaction has to be completed)
5. In the process of updating it will communicate with enqueue and obtain the lock on the document so that no other user updates it.
6. The update request goes to the database.
7. Database process handles the request and checks whether table, table definitions and execution (Cost based optimizer) path are valid.
8. All the update requests goes to the database and lock the record in the database so that no user update it.
9. Database process keeps a copy of the record in roll back segment PSAPROLL/ PSAPUNDO table space to roll back in case of CRASH/ System Failure.
10. Gets the record to database buffer for modification (No record is modified in the database directly)
11. As the database buffers need to be accessed by user modifications are not performed in DB Buffers instead in log buffers.
Eg. Consider a pan shop
Customer - Cigarette Paper - Accounts book
Log buffers are a small area around 1Mb - 4 Mb. As the log buffer is small the content is moved in to Redo logs periodically.
Redo logs are duplexed (Mirror logs and Orig Logs) and ensure that the data is updated in the database.
12. The committed data is updated into database 13. The locks are released and rollback gets invalidated. Note: Committed data can be updated or Redo.
14. User gets the response that the record is updated. ORACLE
Oracle is a database that is used by 2/3rd of SAP Customers. In order to support SAP Customers it is mandatory to know the database management.
Oracle is provided by Oracle Corporation which owns (PeopleSoft, Seibel, JDEdwards, and other small software's to compete with SAP.
Oracle is a proven, well spoken among customers, strong, reliable, consistent, robust database to handle any amount of data in Terra bytes.
Microsoft SQL Server from Microsoft, DB2 from IBM and SAPDB(MAXDB) from SAP shares the remaining 1/3rd of SAP Customers.
Versions
Oracle has versions of database
SAP License is costlier on Oracle than any other combinations.
SAP R/3 4.6C 8.1.7
R/3 4.7 and ECC5.0 9.2.0.2; 9.2.0.4; 9.2.0.6; 9.2.0.7
ECC6.0 10.2.0.2.0; 10.2.0.2.4