1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 …
- What is a SAP Landscape? What is my role in a SAP implementation?
A normal SAP landscape consists of a Development (DEV) instance, a Quality Assurance (QAS) or Test (TST) instance, and a Production instance (PRD). Some very small implementations will have only a DEV and PRD instance, with the DEV instance containing a QAS client for testing purposes.
A non-Production SAP server should have 2 (preferably more) processors, at least 4 gig of memory, and at least 100g of disk space. A Production SAP server should have at least 4 processors, from 4 to 8 gig of memory, and at least 200g of disk space. A hefty server with 6 – 8 processors, 6 – 8 gig of memory, and at lease 200g of disk space can host two SAP instances. This can be done for DEV and QAS but PRD should never share a server with any other SAP instance.
The SAP instances form the core of a SAP landscape. The other installed SAP products are peripheral to the SAP instances.
See Also:
List of SAP BASIS Transactions
- What is a SAP Instance?
A SAP instance is all the components created by the SAPinst program who all share the same database. There are three mandatory sub-instances; the Database Instance (DB), the Central Instance (CI), and the Dialog Instance (DI) aka Application Server. This is the minimum configuration of any SAP instance. There can be multiple DIs but only one DB and only one Active CI which means that a copy of the CI can exist for High Availability but only one of the CIs can be active at any given time. You will hear about SAP being multi-tiered and that term is referancing these three layers. Sometimes you might see “other SAP tiers” like ITS but that really isn’t a separate tier, it used to be an additional piece of software working with IIS, and now ITS is part of Basis/WAS so it is part of the CI Tier. These layers, plus other SAP written software, are also known as the SAP Business Framework.
You can probably guess at what the DB contains. There are any number of tables in a SAP instance, from 21,000 to 38,000. Many have four or five character names that are usually abbreviations of things like USR for user, MANDT for client, etc. You could guess that USR is short for user. But MANDT? So, we add one more variable to the equation – those four or five character names are abbreviations of German words. Needless to say, trying to look at SAP from a typical DBA prospective is almost impossible. Fortunately, SAP supplies the tools for you to manage all these tables.
The Central Instance is a lump term for all the SAP executables, the installed OS file structure, and anything that is placed on the OS to support and communicate with the SAP instance. It “talks” to the database, handles requests made by the application server(s), and sends back the information. Other software products often call this the middleware layer.
The Dialog Instance connects the users to the CI, passes the issued requests to the CI, and sends the returned results to the user’s session. SAP uses a client piece called SAPGui which handles the user-to-DI communication on the user’s workstation.
These are the three main pieces of a SAP instance installation. There are other parts that can be added for various sub-access and external tasks. For a Development SAP instance or a Quality & Assurance or Test SAP instance, all three layers are normally installed on the same server. For a Production SAP instance, the DB/CI are often installed on one server and the DI on another server for load balancing purposes. It should be noted that the installation of a CI instance automatically installs a DI which can be used by everyone if needed, be used only as needed by Basis staff, or never be used.
Instance can be a difficult term to understand – almost every major database applies this term to the installation of the database software. So if you see reference to an Oracle instance, this means the installation of the Oracle software. An Oracle database is the creation of a new empty database within that Oracle instance.
Understanding the Startup and Shutdown prodedures may help solidify this layer concept.
The normal SAP instance start up consists of three parts: starting the SAP OS Collector, starting the Oracle Listener, and starting the SAP instance. The process mainly goes like this: ora<sid> logs on and starts the Oracle Listener then <sid>adm logs on and runs the startsap script.
What? You say we missed a step? What happened to the SAP OS Collector?
The startsap script takes care of the SAP OS Collector for us. When the SAP Instance starts up via the startsap script, it checks to see if saposcol is up and running – whether from the root user starting it manually or from another SAP Instance already starting it up, it doesn’t matter. If saposcol is up and running, the script simply moves on to the next step. If it is not, the script starts saposcol as root and then proceeds. So the SAP OS Collector gets handled one way or another.
However, you may need to bring up multiple Oracle Listeners depending on the database configuration. If the MCOD installation option was used then only one Oracle Listener is used since both databases share one Oracle listening port which is normally 1527. If, however, two Oracle instances were installed, and each database uses its own unique Oracle listening port, then multiple listeners must be started. The startup procedure for each SAP Instance would be exactly the same as if only one SAP Instance resided on the server.
The process to stop the SAP instance is close to being the reverse of the start procedure. <sid>adm stops the SAP Instance, ora<sid> stops the Oracle Listener, and root stops the SAP OS Collector. The only real difference is that saposcol is not automatically stopped by the stopsap script – there may be other SAP instances on the server which means this software needs to stay up and running to gather OS information until that instance comes down.
One thing to note – the Oracle Listener does not start the database, it simply “watches” port 1527 for any database related activity. The startsap and stopsap scripts handling the startup, mount, opening, and shutdown of the database. None of this activity could occur if the listener was not “polling” port 1527, relaying the requested database function, and returning the results through the same port.
The <sid>adm and ora<sid> users are assigned environment variables using the SAP installation run that identify them as users of a specific Oracle database and SAP instance. So when oraabc starts the lsnrctl program with the “lsnrctl start” command, oraabc’s environment variables tell the server which database for which the listener is to “listen”.
- What are the different kinds of SAP software? What kind of hardware will they need?
Although the most common flavor is SAP is called R/3. This is SAP’s main ERP product that handles Financials, Controlling, Logistics, Sales, Human Resources, and lots and lots of other ERP stuff. All these modules – that is what the functional people call them – live in and use common data in one SAP instance. All the modules are installed during a SAP instance installation. Whether all the modules are implemented is up to the SAP customer.
Each SAP “flavor” must be installed in its own SAP instance. Products such as APO (Advanced Planning & Optimization), BW (Business Warehouse), CRM (Customer Relationship Management), SRM (Supplier Relationship Management), SolMan (Solution Manager), and SCM (Supply Chain Management) are all SAP “flavors” installed into their own instances all of which are pretty much installed the same way – installed with a DB, CI and DI - and the process is pretty much the same depending on the age of the product. Just like SAP’s product line, its installation program SAPinst has changed over the years as well.
In addtion, there are add-ons supplied by SAP. Products such as plug-ins for communicating with other SAP instances; the SAP Learning Solution, Sarbannes-Oxley, Best Practices, etc. can be added to an existing SAP instance. These add-on products are what the name implies – they “add” more functions and data “on” to an regular SAP instances.
Some SAP transactions communicate with external software but the functionality is either in the SAP instance or out on your network or on the internet. SAP transactions like SCOT use built-in communication ports for the use of sending email from SAP to a SMTP server. Transaction SICF activates business packages for access via the internet.
RFC – Remote Function Calls – can originate in the SAP instance and go out to “talk” to some other product that knows what to do with the request passed, and information is send back into the SAP instance. And, of course, an SAP instance can talk to another SAP instance using RFC – for example, this is how the Transpost Management System moves changed from one instance to another. There are also products written by SAP partners which can be accessed externally from a SAP instance: products like Vertex which is a Sales Tax database, and BSI which calculates payroll taxes.
As for hardware, SAP has special “hardware sizing” software on which it trains it’s hardware partners like IBM, HP, Dell, etc. They have worked together to create templates for very small, small, medium, large, and very large SAP landscapes. Once you contact the hardware vendor of your choice, they will meet with you to calculate your SAPs – a unit of measurement SAP uses to estimate workload – decide into which category your company fits. From there it is pretty much a plug-in the company data and spit out a sizing reports.
Let’s get this out into the open early: a Basis consultant does not do hardware sizing. Normally, they will look at the sizing report from your hardware vendor and tell you if they think it is too weak or too string. That is about all you can expect of them – their career could be very short-lived if they say “Hey, they are just trying to get you to purchase some really expensive boxes that you just don’t need!”. Remember, SAP created the sizing program and trained this hardware vendor on it and that is what your quotes will be based. Anything critical said about the proposal could get back to all sorts of people who could more or less hurt you in certain circles. I’m not talking about punching you out or stalking you. More along the lines of every problem message you open with SAP gets its priority bumped down to like a -5.
Also, we recommend that you get hardware estimates from more than one hardware vendor. Even if you mentally are locked into an IBM box running AIX and Oracle, it doesn’t hurt to see what the other platforms are selling for. And it doesn’t hurt if rumor gets back to IBM that you are talking to Dell. Playing hardware vendors against one another can lead to some hefty discounts given by a vendor who doesn’t want to see a sale walk out the door.
You can get a head start on the hardware sizing process by reading the documents available at http://service.sap.com/sizing. If nothing else, you can impress your hardware vendor by sprouting out all these SAP terms like SAPs and High Availability and SANs.
Besides servers for your database and SAP instances, you might need other servers for your SAP landscape depending on the complexity of your SAP implementation. At the very least, you will need an additional not-too-hefty server for a Solution Manager instance which is what SAP is now requiring as the “tunnel” to get into your SAP landscape; you’ll need a small server having a public IP address and located in your DMZ for your OSS connection. More about this later.
And there may be a need for Portals servers, UME server, a SAPConsole server… the list goes on and on. As stated earlier, a SAP landscape can be very simple or very complex.
Remote installation on your SAP servers can make the installation task simpler – it is always more comfortable to do the work from your own workstation than having to sit in a cold, noisy computer room. The Basis group of Hitachi recommends Terminal Services – aka Remote Desktop – for this work. PCAnywhere and products such as Tight VNC do not possess the stability of Terminal Services.
- How does SAP get installed?
First, it must be noted that only the SAP company is allowed to KT (Knowledge Transfer) installation information. Clients may watch all they wish during installation, and are encouraged to install and delete sandbox instances on a spare server rather than let it gather dust. But installation is not part of your purchased Technical Knowledge Transfer package.
Without getting into the little details, here is what gets done during the typical SAP install – the work that gets done after the hardware has been installed into the network and DNS:
1. Make all server configuration adjustments as specified in the SAP installation guide.
2. Download and install JDK 1.4x – you can use JRE 1.4.x if you aren’t going to use the ABAP add-on.
3. Install the database software.
4. Patch the database software.
5. Run SAPinst to install the CI and default DI instances.
6. Run SAPinst to install the DB instance.
7. Run SAPinst to install any additional DI instances.
8. Download and install the most current SAP kernel.
9. Current the TMS for the SAP instance.
10. Download and apply all outstanding SAP patches.
11. Request and apply the permanent license key.
12. Do remaining post-installation work such as connecting SAP Online Help, creating clients, adding users, etc.
Normally the post installation work takes 2 - 4x the amount of time of the actual installation. The installation itself normally take a one eight hour working day and the post-installation work two eight-hour working days for a total of three working days to install a SAP instance. This regardless if it is a DEV, QAS, or PRD instance.
See Also:
List of SAP BASIS Transactions
Thanks for Sharing this in depth SAP BASIS Material….
Thanks a lot..