sap basis是从事sap系统管理的一个角色。主要负责sap系统的规划，安装，配置，管理，监控，维护，调优等。 sap basis从具体工作内容的偏向角度，可以分为实施和运维。实施偏向规划，安装，配置等；运维偏向管理，监控，维护等；调优是需要综合考量的，往往更偏向 于实施，但并不是绝对。一般而言，对于sap basis实施的顾问要求应该高于运维。实施规划安装配置了系统，理论上还应该交付大量文档，也就是说定了大局，运维主要是在这个大局已定的前提下做好日 常工作，有点萧规曹随的意味。但是并不代表着实施就一定在所有方向上都比运维专业，因为各自的领域有所偏差。同时，有一点很重要，就是数据的安全，所以， 资料库备份和还原是需要认真掌握的。

sap basis需要了解os,db,sap以及network等相关知识，才能更好的履行职责。

sap basis应该学习的sap标准文档，包含adm100,adm102,adm105,adm106,adm200,bc315,adm325,adm326,adm505，bc660,adm940等等(请采用二级标题逐渐补充,内部小标题采用粗体表明)。

adm100相关介绍

sap系統和sap instance:

一个sap系统通常包括了一个相应的资料库系统，一个或者多个sap instances。 这是通常的说法。 举个例子，我们说的开发系统，测试系统，生产系统，往往都是说的一个sap系统。 这个系统自然都包括了各自的资料库系统以及sap实例。 而资料库系统，包括了资料库的数据文件，参数文件，控制文件，日志文件以及资料库实例。 对于实例的解释，我们可以认为是一组紧密关联的作业系统进程，往往，这些进程具有父进程和子进程的关系。 举个例子，在unix下，我们的dialog进程，background进程等等都是调度器进程的子进程。 我们可以通过察看进程的pid以及ppid来证实这个。 而且更进一步的说��，这些进程实际上运行的是同一个可执行程序，只是在根据启动的类型和实例参数而不同。 对于CI和DI的区别，传统的说法是CI有messager和enqueue服务。

登陆sap系统的过程：

在前端，即Presentation workstation出于个人知识有限，我只讨论使用saplogon或者saplogon pad登陆sap系统的过程。首先明确一点，这两种方式，最终都是通过调用sapgui.exe来登陆系统的，而sapgui.exe的参数，往往是通过 saplogon.ini来确定的，saplogon.ini的配置，往往是通过saplogon. exe的图形化界面来编辑的。所以，我们实际上可以直接在sapgui.exe所在路径下，运行命令行命令来登陆系统。比如sapgui.exe /H/<server name>/S/sapdp<system NO>或者sapgui.exe /M/<Message Server Name>/S/sapmsSID/G/<Logon Group>。这个请参看bc305

在sap系统的过程：基本过程是一个sapgui.exe相关进程同伺服器的messager进程，dispather进程及子进程(比如说 dialog进程)的依次通讯。用户首次登陆，都首先会跟message进程通讯，然后才由message进程分配到某一个实例的dispather，在 重新登陆之前用户都不会被调度到别的实例，然后用户会话的每一个dialog step，都会通过dispather调度到可用的dialog进程。因此也产生了一个现象，就是，用户运行一个事务，可能它对应的多个dialog step会在不同的会话进程上运行。

在资料库层面;当需要更新或者查询的时候，sap的进程首先是通过作业系统认证的ops$用户跟资料库连接，然后获取sapr3或者sapsid 的密码跟资料库重新以sapdba角色连接。所以，从sap的角度来看，就数据更新许可权的object级别管理，在sap，不在资料库。

关于loading balance,这个往往需要多个instance的时候才会比较有用，主要功能是更有效的利用的sap的program buffer（我个人认为主要是workload balance，这一点在大型系统特别有用，可以将DB+ CI上dialog用户切换到其他instance上，然后DB可以加大database buffer,提高命中率，进而提高整个SAP系统的性能）配置起来是比较简单的，只需要用smlg就可以创建logon group。可能一个需要提醒在用户端，需要在windows\system32\drivers\etc的services文件里添加sap服务，然后 用saplogon.exe去生成logon group （实际最终就是编辑了saplogon.ini之类文件）。

sap系统的启停:

sap系统的sap实例的进程，都是运行在作业系统用户SIDadm下的。 sap启动大致过程是，首先启动资料库，然后是SAP CI，然后是DI.对于资料库的具体启动过程，我准备放到bc505自学笔记里面。这里我们主要谈sap CI启动过程。 sap的启动跟sap启动配置文件，默认参数文件，实例参数文件，以及启动时使用的用户都有关系。 adm100上提及了在db正常启动了之后，首先是启动一个独立saposcol，然后才是messege服务，然后才是dispather，然后才是 work process 0。 。 。 。 。我想补充的是，从message服务开始，都跟启动配置文件，默认参数文件，实例参数文件有密切关系。这个可以通过查看启动配置文件去得到充分的证实。 对于启动问题的trouble shooting，关键在于，一是定位出问题的启动问题环节，二是找到该问题环节的日志文件。有了这个明确的思路，参照adm100，就不难去查找问题 了。大致的log文件，资料库log自然在资料库日志路径查询(不同资料库都有差异，限于个人接触有限，就不细说了，如果谁能提供，非常欢迎)，sap 的，主要是在/ usr/sap/SID/<Instance>/work下查询。当然，对于启动问题的处理，背后的种种原因，已经超过了adm100所有涵 盖的范围。如果大家愿意，我真心希望能提供各种类型的问题案例来丰富。

对于sap系统的停止，大体说是检查和终止系统未结事务，关闭sap实例，然后是停止db。但是对于复杂的企业系统架构，其实还涉及到关联系统的启停配合，这是需要考虑到的。

sap系统配置:

在前面我们多次提到了，sap实例，最终最典型的是由sap实例参数文件来决定的。 adm上面提到了，参数文件的读取顺序是优先顺序由低到高的，首先是系统默认(sap kernel等)，然后查找DEFAULT.PFL的参数，然后是实例参数。优先顺序高的参数会覆盖优先顺序低的参数。这就是为什么，我们刚安装好的 sap系统参数少的可怜，仍然能够按照一定参数启动的原因。这里需要注意的是关于参数文件命名规范以及sap参数文件维护。就sap参数文件的维护，我们 必须明确一个修改前备份修改激活前先检查的原则，而且，要明确知道，sap参数文件，存在资料库存储和作业系统文件两部分(active的部分)。起作用 的是作业系统文件部分，而进行版本管理的则是资料库存储部分。当我们首次要维护参数文件文件是，首先应该是rz10去import from active。当我们需要生效一个参数文件的时候，需要保存并激活该参数文件。此外的细节是，就某些参数，是可以用rz11动态的去调整的，当然，很明显 的是，动态调整的参数并没有保存到参数文件，所以重新启动系统后，自然会失效。同时，动态调整的参数，如果跟参数文件的参数不一致，我们是可以看到谁最后 修改。就内存参数，虽然不是动态可调整参数，实际上sap也是提供了动态调整的程序rsmemory，当然，这个会具有相当的风险性，慎用。 --奥特曼：所以经常起不来的原因是因为你修改了profile导致10 40两个buffer的池子不够了。一般来说你在激活前如果两个池子太小，系统会提示你，但是也有的时候，系统在那时候不提示你，但是就是起不来。然后 你可以去OS用sappfpar check pf=....（好像是这个命令）来检查。还有就是如果启动的时候出现内存问题，你可以先cleanipc一下（cleanipc?命令又忘了，好久不用 了）---

继续http://zh.wikipedia.org/wiki/Sap_basis