SAP系统和SAP instance:
一个SAP系统通常包括了一个相应的数据库系统，一个或者多个SAP instances。这是通常的说法。举个例子，我们说的开发系统，测试系统，生产系统，往往都是说的一个SAP系统。这个系统自然都包括了各自的数据库系统以及SAP实例。
而数据库系统，包括了数据库的数据文件，参数文件，控制文件，日志文件以及数据库实例。
对于实例的解释，我们可以认为是一组紧密关联的操作系统进程，往往，这些进程具有父进程和子进程的关系。举个例子，在unix下，我们的dialog进程，background进程等等都是调度器进程的子进程。我们可以通过察看进程的pid以及ppid来证实这个。而且更进一步的说明，这些进程实际上运行的是同一个可执行程序，只是在根据启动的类型和实例参数而不同。这同时也侧面告诉我们，为什么SAP各进程能够在操作系统层面存在共享内存。这是通过父进程实现的。
对于CI和DI的区别，传统的说法是CI有messager很enqueue服务。我这仍然有一个疑惑，既然DI没有enq服务，那为什么还要enq参数？
登陆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用户跟数据库的shadow进程建立，然后获取SAPr3的密码然后跟数据库重新连接。所以，从SAP的角度来看，就数据更新权限的管理，在SAP，不在数据库。
关于loading balance,这个往往需要多个instance的时候才会比较有用，主要功能是更有效的利用的SAP的program buffer，配置起来是比较简单的，只需要用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，当然，这个会具有相当的风险性，慎用。
ITS不熟，暂略过，欢迎补充
SAP Help 配置，给个示例。 
transaction SR13，然后选择PlainHtmlHttp tab
创建一个entry,输入一个自定义变量名，platform选择WIN32,Area选择IWBHELP, server names输入help.SAP.com
path输入相应版本的SAP帮助路径，比如SAPhelp_erp2004/helpdata。语种我这里用EN，default我也在EN这栏打勾。
在IE的版本上要注意和GUI的兼容。
数据库监控，备份还原部分，在以后bc505自学笔记中讨论。
SAP系统landscap和传输请求
SAP系统数据分为集团相关和跨集团数据。
集团相关的数据的本质是数据库表第一个主键是MANDT. 跨集团部分包含跨集团定制数据和SAP repository数据。Repository基本上包含了程序，数据结构，表定义，屏幕，函数和类等等数据。
对这些数据的更改，集团相关的数据，通过custormizing request传输，跨集团数据更改，通过workbench request传输。
传输请求(cutomizing request和workbench request)命名规则是<SID>K9<nnnnn> (n是小于10的非负整数)。
传输目的地，可以通过创建request的目标系统或者Group来实现，也可以通过package自动带出目标系统。
传输分为两个阶段，导出和导入阶段。
导出阶段是将数据库数据文件的特定数据导出到传输目录的数据文件R9<nnnnn>.<SID>和控制文件K9<nnnnn>.<SID>。
导入过程则相反，将数据文件R9<nnnnn>.<SID>的数据导入到数据库文件。
相关过程的日志，都存储在/usr/SAP/trans/log下面的ALOG,SLOG,ULOG里面。这些都可以通过STMS的友好界面去查看。
实际的操作过程很简单。就是对于一个request，举个例子，一个三系统架构，一个workbench request，如果在开发系统一个z报表开发好并且激活，而且保存的时候assign到一个task了，那么我们的owner首先用se01去release这个task，然后release request.然后就会触发event去导出数据到request的数据文件和控制文件。release之后，会通过RFC把这个request自动加入到q系统buffer文件中，俗称传输队列，如果各系统没有共用一个传输路径，需要我们手动在stms里面去adjust queue调用ftp命令拷贝文件到q系统，然后在q系统用stms去import就可以导入到q系统.在q系统导入后，也会通过rfc通讯将该request加入到p系统buffer文件。依此类推。
在导出和导入过程，操作系统层面关键程序是tp.exe，SAP层面是event triggered的job RDDIMPDP。如果感兴趣，可以直接看RDDIMPDP的program documentation.通过对RDDIMPDP的功能的了解，我们就可以理解为什么btc进程至少需要两个，以及为什么btc空闲进程至少要两个才能进行正常的传输，打补丁。
小技巧，SE03可以用来灵活的搜索transport request。
关于打support package，因为本人仅仅做过简单试验，所以仅仅分享下从群里面获取的经验:
1 support package都是在迫不得已的情况下才会选择的，导入之前应当备份系统，先做一次测试导入(菜单栏可以设置extras-〉setting)，导入之后应该进行完善的测试。
2 support package应该在导入语言包之后打，不然会存在语言文本问题，当然迫不得已在之后导入新语言，SMLT里面也有一个special action去导入support package语言部分的功能。
3 support package的导入过程相当简单，就是首先将下载的support package先解压到 usr/SAP/trans/EPS/in路径下，然后就可以define queue，系统会自动去检查前提条件，在开始导入的时候，系统会去检查是否有标准对象被更改过，然后提示是否需要adjust modification。导入成功后需要confirm。
通常我们所说的support package 如下。这些是用SPAM去导入的:
SAP_BASIS (SAP Basis Support Package) SAPKB<rel><nr>
SAP_ABA (Application Interface SP) SAPKA<rel><nr>
SAP_APPL (SAP R/3 Support Package) SAPKH<rel><nr>
SAP_HR (SAP R/3 HR SP) SAPKE<rel><nr>
SAP_APO (APO Support Package) SAPKY<rel><nr>
SAP_BW (BW Support Package) SAPKW<rel><nr>
而add-on应该用SAINT,打notes用SNOTE。 具体的暂时略过，等有经验和研究再补充。也欢迎高手补充。
对于系统升级，因为目前没有实践过，暂不妄谈。
SAP后台作业管理
后台作业，主要用于运行需要处理大量数据，对交互没有要求的程序。个人认为，简单的创建，配置和监控后台作业没有什么难度。后台作业管理最为困难的解决方案的取舍，系统负载的调控。失控的后台作业，往往对系统带来灾难性的性能问题，也会导致权限管理的风险，结果是得不偿失，而且可能导致流程混乱。所以个人认为，要创建一个周期性的后台作业之前，首先应该慎重分析。比方说，一个已经明显偏向 OLAP类型的报表，如果能够用BI去实现，为什么还要坚持在生产系统去跑长时间的后台作业？这极有可能是一种严重的重复运行的性能问题。再比方说，用户获得授权随意创建后台作业，结果导致后台作业失控，在业务繁忙的时候，因为大量的后台作业导致整个系统的停顿，会造成实实在在的经济损失。再比如说，后台作业安排的不合理，可能耗资源的和重要的后台作业直接或者间接安排到了同一个时间段，那么必然会影响流程的运作。
下面详细解释一下SAP得后台作业。
SAP得后台作业的启动方式可以是定时地，也是可以是事件触发的。后台作业里面包含一个或者多个步骤，每一个步骤则包含调用的程序，外部shell命令以及外部程序，也包含了调用者以及变量，还可以定义打印参数。后台作业的名字往往需要遵循一定的命名规则，用来明确该后台作业的重要程度，启动方式，作用等等。我们往往通过SM36去创建后台作业，（也可以通过SM36去查看SAP标准后台作业），通过SM37去监控和管理后台作业。
后台作业有Scheduled, Released, Ready, Active, Finished, Canceled六种状态。另外还可以指定执行的服务器组(后台job执行的服务器组可以用sm61来配置)。
Scheduled状态的job是创建了但是还没有release，这种状态的job是不会跑的。Released状态的job在启动条件满足后会启动，Ready就是启动条件满足后，系统开始为该job分配但尚未分配合适的后台进程的一个中间状态，Active代表这个job正在运行当中，换言之，其相应的后台进程正在运行job某一个step得程序;Finished代表job得所有step都成功的完成了。Canceled代表job在某一个step得运行过程中异常中止了。
SAP job得信息存在一系列的表TBTC*里面。有的时候，某个job对应的进程中止了，但是表里面的状态信息仍然没有更新，会出现job是active状态，而实际没有进程在跑的情况，那么，我们只需要check status，就可以手动修正表里面的状态信息。
如果要分析job cancel得原因，应该检查job log，往往job得step都是跑的是abap程序，所以，job cancel得时候常伴随着dump产生，这个时候，双击job log的条目，可以跳转对应的dump。另外，有的时候，因为进程被中止导致的job cancel没有被写入日志，需要结合system log去分析。job log是保存在\usr\SAP\SID\SYS\global日志文件<client nr>JOBLOG中的，在某些特定的情况下，日志文件访问问题会导致所有的job cancel,在DI上出现这种问题的时候，据说可能是NFS不稳定，这个我还不确定。
触发Event 基本本是function module BP_EVENT_RAISE或者SAPevt.exe。
SAP打印
完整SAP打印过程基本上是：
1 选择打印的文档，创建spool request(printer-independent);
2 如果是立即打印，则根据output device创建output request(printer-dependent)；
3 output request被移交给SAP print process处理
4 SAP print process将打印数据转换成打印机可识别的格式移交给操作系统打印管理器。
在adm里面强调了一点，就是如果操作系统层面打印机不可用，对SAP来说该打印机也不可用。
此外，SAP打印机的access method，主要和操作系统差异(NT,Unix)以及SAP print process和os spooler所在服务器有关.
Access Method: F类型是针对用户端为windows平台，具体是通过SAP spool->SAPlpd->windows spool实现的。
L(调用unix shell command lp/lpr)和C(调用windows API)类型分别对应unix和winodws平台的应用服务器得local类型，local类型的意思是SAP print process和os spool在同一物理服务器上。
U和S分别针对unix平台和windows平台的远程打印，远程打印的意思是SAP print process和os spooler不在同一服务器。需要说明的是，s类型还是需要调用打印服务器端的SAPlpd.
下面大致说明一下简单的SAP 打印机配置过程(oms得复杂类型配置暂且略过，我还没有做过)
一般我们配置的打印机(output device)多为L类型的。
SPAD创建打印机
output device:大小写区分
device type:选择对应的型号，如果没有默认的，首先去SAP官网下载最新的device type导入，如果还没有，就去供应商官网查找。SAPnote 8928
delievery classs: 打印机用standard printer
authorization group: 打印机权限管理，不需要可以略过(我没有配置过)
Model,location, Message都是描述性字段，根据各公司的命名规则去填写，以便实际管理
lock printer in SAP System: 是否在SAP系统锁定该打印机？当然不了
Host Acces method：L
Host Printer Name: 打印机名称(这个字段将用于lp/lpr命令)
Host Name：打印服务器机器名(比如我的打印机安装在sidhau上，那么这一栏自然就是sidhau)
一般为了性能良好，都将Do not query Host Spooler for output status打上勾。
其他默认。
关于F类型打印机我就不详细说明了，下面贴一个SDN关于PDF1打印机配置的BLOG。这个包含了F类型打印机配置，同时给出了不用第三方软件提供将报表转pdf格式文件得解决方案。已测试通过。
对于spool得维护和监控也是相当重要的。需要定期清理旧的spool request和output request.
SAP有标准的后台作业SAP_REORG_SPOOL( rspo1041)和SAP_CHECK_SPOOL(rspo1043)详细信息可以查看SAP note 130978和98065.