SAP

General:

SAP support
https://wwwp04.sapnet.sap.com/~sapidb/011000358700000028241999E/mask.htm
https://wwwp04.sapnet.sap.com/

Principio

SAP Process

• -v/volume es para sobreescribir.
• -a Para hacer backup de los datos y de los ficheros de repetición de modificaciones en la misma cinta y no por separado.
• -check Es para comprobación del sistema, genera un fichero llamado <DateTime>.chk en el directorio sapcheck.
• -next para hacer las extensiones desatendidas de las tablas. Genera un fichero del tipo <DateTime>.nxt para comprobación.
• d - Reorganization igual que el anterior pero para un solo objeto.
• c - Tablespace administration Para extender "tablespaces".

• gwrd
• sapstart
• oninit
• ora_ckpt_<SID>
• ora_lgwr_<SID>
• dw.sap<SID>_DVEBMGS02
• se.sap<SID>_DVEBMGS02 mensajes a la instancia central de los co, procesos colectores.
• co.sap<SID>_DVEBMGS02
• ms.sap<SID>_DVEBMGS02

Si el proceso se.sap se para hacer:
ext
  Author: Christiane Schad
  Date:  13.03.1996
  Filename:  \os\cookbook\applicat\sap\sapprocs\rslgsend.sam

  1. Check whether the link of the se.sap process still exists in the
  workdirectory
  /usr/sap///work
  e.g.:  /usr/sap/TS2/DVEBMGS00/work

  if not check the start profile for the syntax of how to link it:
  /sapmnt//profile/START_
  e.g.: /sapmnt/TS2/profile/START_DVEBMGS00

  2.  To restart the send process you must be adm and in
  the work directory

  nohup ./se.sap_ -F
  pf=/usr/sap//SYS/profile/_ &

  nohup ./se.sapTS2_DVEBMGS00 -F
  pf=/usr/sap/TS2/SYS/profile/TS2_DVEBMGS00 &

  NOTE: for the syntax you can check either one of the
  stderr files or the STARTprofile

  3. Check the PID of the restarted process and update the
  shutdown.sap file in the workdirectory:
  check which of the PIDs is the one of the old/died se.sap
  process and replace this PID with the PID of the restarted
  process.
  If the shutdown.sap file will not be updated, the se.sap process
  will not be stopped when  stopping the SAP system.

Startup down

                  The SAP-process "sapstart" starts the following SAP-processes:

                  1.) Message-Server (ms.sap...)
                  2.) Dispatcher (dw.sap..., which then starts all other dw.sap-procs and the gwrd-proc)
                  3.) Syslog-Collector (co.sap...)
                  4.) Syslog-Sender (se.sap...)

                  After the successful start of R3, the process "sapstart" stays alive waiting for a
                  "kill -2" signal to stop all of the above processes in reverse order.

                  ==> If "sapstart" dies, the next shutdown of R3 will fail (and thus most likely the
                      next startup)!!!

                  Solution:
                  =========
                  Edit the file "kill.sap" in the SAP-work directory to look like this
                  (remove existing line):

                  Note: the correct PIDs are most easily found using the command

                            ps -ef | egrep 'se.sap|co.sap|gwrd|ms.sap' | grep -v egrep

                        where the Dispatcher-PID is the PID of the father process
                        of "gwrd"

                  kill -2 <PID of se.sap...>
                  kill -2 <PID of co.sap...>
                  kill -2 <PID of Dispatcher>
                  kill -2 <PID of ms.sap...>
                  sleep 10
                  ipcrm -m <Shared Memory Segment of sapstart>
                  where <Shared Memory Segment of sapstart> is the second number found in the file
                  "sapstart.sem" in the SAP-work directory.  (Without the "ipcrm"-command, R3 would be
                  shutdown correctly, but the stopsap-script would be forever waiting for the cleanup
                  of resources.)

                  Now, when the next "stopsap" will be executed (e.g. for the next offline backup),
                  R3 will be stopped gracefully.

                  Don't forget to edit the process monitoring configuration and leave your call open
                  until you have reincluded sapstart in the process monitoring after the next restart
                  of R3

• To start the r3perfAgent

1. nohup /home/p10adm/sap_perf_start &

Arrancar y parar R/3

Principio

Profiles:

Principio

Ficheros de alertas:

Principio
 

Ficheros de control o log.

Principio

Bases de datos (Oracle)

Principio
 

Definición de autorizaciones:

Principio
 

Impresión:

1. Local
2. Debe el hosts receptor tener corriendo el demonio lpd.
3. Metodos de acceso:
4. L para sistemas Unix, utiliza lp o lpr.
5. C para sistemas NT, llama a la API de Windows.
6. Remoto
7. En NT SAP proporciona el demonio y lo llama SAPLPD.
8. Metodos de acceso:
9. U Para sistemas Unix
10. S Para sistemas Windows.
11. Método de acceso F, para imprimir en impresoras sin configurar en R/3, se deja que sea el sistema operativo utliza sus drivers.

Principio

FTP

Para hacer FTP ha clientes tenemos que pasar por el firewall, osctrl06, sftp 192.6.53.25 o stelnet 192.6.53.25

Principio

System monitoring

Principio

Parameters

Principio

Tools

Principio

Ficheros de alertas Oracle:

1. Fichero de alertas Oracle /oracle/<SID>/saptrace/background/alert_<SID>.log
2. Fichero para hacer "traces" /oracle/<SID>/usertrace/ora_<pid>.trc
3. Logs en R/3 $home/<SID>adm/startsap_<hosts>_<instance_no>.

Principio

Transportes / Ciba

Transportes:

1. Hacer login como superusuario y cambiar al superusuario de SAP su - <SID>adm.
2. En el directorio Unix /usr/sap/trans/bin
3. En NT puede ser O:/bin o O:/usr/sap, no obstante el programa tp debe estar accesible desde ese directorio.
4. Meter en el buffer con tp addtobuffer <transporte> <SID>
5. Para importar desde el buffer tp import <transporte> <SID> client[=]<número> u48 {Modo incondicinal, 0 para mantener en el buffer}

A partir de la versión 4.0 existe el llamado TMS o Transport Managment System.
El fichero de configuración del programa tp para transportes es /bin/TPPARAM y debe estar dentro del directorio destinado a transportes.
Transacción SSC1 transporta sin borrar datos.
Nota: Mirar la transacción se02 en la instancia de origen para comprobar que el nombre del transporte y la fecha son correctos.

Principio

Ciba transportes:

1. Desde el directorio /home/pe1adm/ctrans ejecutar el script, ./ctrans. (Sistema posape1).
2. Iniciar la sesion SAP la máquina powdb (D11) y la transacción /nb12 para ver el listado de los transportes.

OSS notes:

1. Login in the system as:
2. Client:001, user: see phone.exe is the bussines entry. (Is in O:\OS\DUTY\)
3. Passwd:
4. Transacction BIBO.
5. Gen. Funtions -> Find, fill the fields to search.

Other notes:

• Unlock SAP user via SQL.

If a SAP-user is locked and you have access to the
  database, just try this SQL-command:

  update SAPR3.USR02 set UFLAG=0 where BNAME='HP' and MANDT='000';
  commit;

Connect Direct: install / check / start and stop

• run the cmviewcl to check if the service guard is running. If is running only edit the service guard file. And do the instalation only in the system specified in the request.
• Insert a new user for the only OUTbound Interfaces (in lock mode vipw) (In both system with the same ID if service guard is running).
• Look if the file /interfaces/netmap.cfg has one entrance with these system, the both systems has to be there.
• Edit the file /interfaces/etc/interfaces.cfg  to install the interfaces. INTERFACE PARTNER [I|O]
• Execute the script /interfaces/bin/ds.ksh
• Edit the file /interfaces/userfile.cfg (userfile.sg.cfg) and append the file /interfaces/etc/new_userfile.cfg
• In Inboud search in the file /interfaces/<Interface>/bin/execute.bat if is [evnt|trigger|startrfc] If the scheduling is "start scheduled" then is trigger by SAP, comment the start line.
• In Outboud depending on the type of the system, leave the the /interfaces/<Interface>/bin/copy1.sh file if is Unix, copy on it the NT or tandem
• In Tandem change the name of the Directory or File to the name indicated in the form.
• Check Connect Direct

• Does the deamon run?
• ps -ef | grep cdpm
• If it is an Inbound interface inform the customer.
• Inbound is e.g. DVIMAGP )
• If it is an Outbound interface try to resend the files with:
• /interface/<interface>/bin/copy.sh
• Outbound is e.g. DVOMAGP (third letter is O)
• check the log files in:
• /interfaces/log/<interface>.log
• or:
• /home/cduser/cdunix[sg]/work/<server>[sg]/S<year><month><day>.001
• Start and stop
• stop
• ps -ef | grep cdpmgr
• su - cduser
• kill <PID>
• start:
• as Root
• cd /home/cduser/
• ./start.ksh

Principio

Archiving logs full:

• Log on in the system wich has the file system full
1. su - <sid>adm (su - ora<sid>)
2. svrmgrl
3. connect internal
4. archive log list Look wich is the archive destination. Find wich is the log-prefix (p.e.:WPRarchb)
• Log in the system in Unix level
• Change to the directory where we want to switch the destination of the arch files
• Find a file system with space enougth.
• make a temp directory
• In the server manager system do
1. archive log start '/New-Directory/log-prefix'
2. alter system switch logfile;
• After the backup the file system should have space, copy the files in New-Directory to the first one and switch back to the previous system.

Free statistics space: 23-Jul-99

1. ST03 -> Workload -> Reorganitation ->  Delete statsfile.

Oracle Archiver is stuck ( Filesystem .../saparch is full): 13-Oct-99

Beware:  Do not resolve the "archiver stuck" situation in the way
                     described here, if a permanent recovery solution (PRS) is in place,
                     since the prs_copy process would not find the redirected Archivelogs
                     anymore!!!

                     1) use bdf to find a file system with enough free space to hold
                        several archivelogs

                     2) create subdirectory "archives_tmp" in this file system

                     3) chmod 777 archives_tmp

                     4) su - orasid

                     5) sqldba lmode=y

                     6) SQLDBA> archive log start '.../archives_tmp/SIDarch'
                        (BEWARE:  svrmgr expects
                        SVRMGR> archive log start to '.../archives_tmp/SIDarch')
                        This redirects the archivelogs to the newly created directory.
                        After the first archivelog has been archived, the archiver stuck
                        situation is resolved.

                     7) use brarchive to backup and delete the old archivelogs in
                        ".../saparch"

                     8) SQLDBA> archive log start '/oracle/SID/saparch/SIDarch'
                        (BEWARE:  svrmgr expects
                        SVRMGR> archive log start to '/oracle/SID/saparch/SIDarch')

                     9) if there are only a few archivelogs in ".../archives_tmp" then:

                        wait until the last archival to ".../archives_tmp" is finished;
                        then move all archivelogs from ".../archives_tmp" to ".../saparch"

                        else:

                        change parameter 'log_archive_dest' in /oracle/SID/dbs/initSID.ora
                        and use brarchive to save the archivelogs directly from
                        ".../archives_tmp"

                        Don't forget to change back /oracle/SID/dbs/initSID.ora, once the
                        brarchive has been started

                     10) rmdir archives_tmp
Principio
 

Howto solve "Filesystem over threshold" Calls: 13-Oct-99

1. Wie es zu diesen Meldungen kommt
            Diese Meldungen kommen aus einem Überwachungsskript:
            /var/opt/OV/bin/OpC/monitor/df_mon das alle 15 Minuten auf den Rechnern läuft.

            Dieses Skript überwacht anhand der Auflistung von FS im File /var/opt/OV/con/Opc/df_mon.cfg

            Generelle Vorgehensweise:
            Handelt es sich um ein FS, das nichts mit SAP zu tun hat, geht der Call weiter ans Recovery Team

            Ansonsten cd in das betreffende Verzeichnis und dort "bdf ." ausführen, um zu prüfen,
            ob das Problem noch besteht oder ein temporäres Phänomen war.

            Mit du -xsk * lassen sich die größten Beiträger ermitteln. Achtung: Die darunter gemounteten
            FS tauchen hier leider mit auf, obwohl sie natürlich keinen Beitrag zu dem Problem leisten.
            In das entsprechende Verzeichnis mit dem größten Beitrag wechseln und dort wieder mit
            du -xsk * die größten Files/Unterverzeichnisse ermitteln, bis die Ursache - meist ein großes
            File mit heutigem Datum - gefunden ist.

            Hiermit erhaelt man meistens einen sehr guten Ueberblick ueber die Verursacher des Calls:
            find . -xdev -mtime -3 -size +50000c -exec ll -d {} \;
            Dieser Befehl zeigt nur Files an, die in dem betroffenen FS liegen (keine Unterverzeichnisse
            mit anderen FS werden durchsucht), die vor maximal 3 Tagen veraendert wurden und
            die mindestens 50000 Zeichen gross sind.

            Wenn man gar nichts findet, kann man alte Files, die schon lange nicht mehr benutzt wurden,
            komprimieren (bitte keine Executables!). Besser auch mit fuser ,file_name> pruefen, ob Prozesse das File in Verwendung haben. Wenn hierbei eine Prozess-ID zurueckgeliefert wird, auf keinen Fall das File komprimieren oder removen.
            Identifzieren von Files, die älter als 100 Tage sind, mit
            find . -name '*' -mtime +100 -exec ll {} \ ;
            genau prüfen, ob man auch wirklich diese File komprimieren sollte (evtl. Rücksprache mit
            dem Kundenverantwortlichen), dann
            find . -name '*' -mtime +100 -exec compress {} \ ;   oder noch besser
            find . -name '*' -mtime +100 -exec gzip -9 {} \ ;
            oder um besonders große Files (in diesem Fall >10MB) zu finden:
            find . -name '*' -size +10000000c -exec ll {} \;

            Unsere "Pappenheimer"
            /usr/sap//D*/work/core kann removed werden

            /usr/sap//D*/data/stat -> siehe Entry Nummer 0f64

            /usr/sap//global/BIxxxxxx oder /sapmnt//global/Bixxxxxx ist die Batch Input
            Protokolldatei. Da täglich sehr viel Batch Input läuft, wächst sie ständig und darf unter keinen
            Umständen von Hand removed oder komprimiert werden. Im Zuge des wöchenlichen Aufräumens
            (ABAP-Programm RSBTCDEL) auf dem System wird diese Datei bereinigt. Siehe auch OSS
            16083) Man kann hier nichts tun, außer den Kunden zu informieren und gegebenenfalls das Filesystem erweitern.

            /usr/sap/trans
            Generell darf man nicht bei allen Kunden alte Transporte löschen - man sollte hier mit den
            Kundenverantwortlichen Rücksprache halten. Wenn löschen ok ist, gilt OSS Hinweis 41732.

            cd /usr/sap/trans/bin
            tp check all
            tp clearold all

            /oracle/SID/saparch oder /oracle/SID/arch_put_reorg
            Hier sollte schleunigst eine Archive-Sicherung angestossen werden,
            wenn die nicht mehr rechtzeitig hilft, siehe Entry Nummer 054a

            Wenn man ein riesiges dev_coll File vorfindet -> siehe Entry Nummer 712280
Principio