David's Untitled Life

首先，在output device中设置是不行的，需要在Sapscript/smartform中设置print mode。

其次，你不能所有的页面属性中都设置duplex mode，那样是错误的，也只能打出来单面。

只需要在第一页设置duplex即可。

http://bbs.pcbeta.com/thread-407723-1-1.html

简单来说，现在争论的人主要围绕着windows的x86和x64版本

但其实这个争论根本和32bit和64bit没有直接关联，只有间接关联而已。
因为大部分都搞错了一个重要的基础，就是x64不代表64bit，代表64bit的东西叫做IA64

说一大堆专业术语恐怕大部分人都懒得看，也看不懂，就简单说概念性的东西。

真正意义上纯64bit的东西只有intel的IA64，它完全不兼容x86运算，需要用到x86-to-IA-64的解码器才能进行x86运算，但是性能损失很厉害。

x64这个东西准确来说应该是x86拓展x64技术，amd和intel的东西根本都是一个性质。
这个技术是用来解决64bit系统处理x86代码需要损失性能的关键，因为它是直接使用x86的cpu拓展到64bit，使x86的cpu即可以处理x86运算，也可以处理64bit运算

和IA64的解码器可以说是完全反过来的东西，IA64的解码器是让64bit的cpu处理被转换成64bit的32bit代码，而x64则是x86的cpu直接处理32bit和64bit的运算。

而争论的关键就在于32bit和64bit的软件，实际上现在我们使用的所谓64bit cpu都是x64的cpu，64bit的cpu只有Intel的安腾系列而已，也只有他们可以安装安腾服务器版原生纯64bit的windows。

而x64的本质就是用来同时处理32bit和64bit，所以在x64上面根本无谓软件的32bit和64bit之分，因为两者都可以非常顺利的运用在x64的构架上面，只是64bit的软件效率比32bit的软件要高得多，但是不代表32bit的软件在x64上面会出现问题，当然这里不包括那些使用16位安装代码的程序，x64抛弃了16位，这你去问微软。

换句话说，想要x64只运行64bit的时代是不会到来，因为x64就是为了同时运行x86和64bit而出现的东西，那个时代只会属于安腾cpu，而不是我们现在手里的拥有x64技术的x86 cpu。
32bit的代码在x64中永远也不回消失，因为那就是x64出现的目的。

As you know, each SAP output device can only have one sort of character set. Generally, each language printout corresponds to each language smartform/sapscript version. But if you have a requirement that you have to be able to print out English with Japanese/Chinses/Thai together, what should we do?

The answer is using Cascading Fonts and relevant device type.

So far only Unicode system supports this tech and there are some preconditions:

You can find that in Note 906031 - Information about cascading fonts device types

And for Cascading fonts setting, please refer to:

Note 812821 - Cascading Font settings and configuration guide at http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/c0169b51-95d5-2b10-469e-f488b2ab5b58

SAP supports TrueType font upload, but what is TrueType font?

Here you go:

http://en.wikipedia.org/wiki/TrueType

http://computer.howstuffworks.com/question460.htm

http://www.microsoft.com/typography/WhatIsTrueType.mspx

http://help.sap.com/saphelp_nw04s/helpdata/en/04/285ea6a87f11d194a400a0c930df15/frameset.htm

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/ebc8ba02-0b01-0010-66a6-cb747fd2a962

今日培训，得知SAP整个application server的启动过程是:

首先dispatcher启动（disp+work），然后dispatcher会进行一系列的初始化工作，也就是说，启动instance其实是启动dispatcher

dispatcher初始化：

• 网络
• shared memory和sempaphore
• 创建工作进程

而工作进程（UPD DIA ENQ SPO等等）的创建，在UNIX上是以FORK的方式，即子进程的方式进行。因为dispatcher和工作进程都是一个二进制可执行文件（disp+work），所以可以很容易的fork子进程。个人对UNIX/LINUX编程是白痴，个人理解，这么做的好处是快速的将系统有关的信息复制到子进程（FORK方式决定的）并且WP的死掉可以被dispatcher所了解和控制。

以下几篇文章作为参考：

http://www.ibm.com/developerworks/cn/aix/library/au-unixprocess.html UNIX 进程揭秘

http://blog.chinaunix.net/u2/63316/showart_509528.html 理解fork函数

http://www.chinaunix.net/jh/23/62948.html 在unix系统中创建守护进程

我们知道，SAP实例内的通信使用IPC或者UDP协议，为了性能。而与实例外系统通信使用TCP/IP协议。而与系统外的通讯是经过gateway的，dispatcher作为调度员控制所有与SAPGUI、gateway、MS的通信。但是有一点例外，为了效率，WP与gateway通信并不经过dispatcher，而是直接进行。

由于dispatcher如此重要，当系统出现hang或down机时，除了相关WP的trace文件外，disp的trace文件是必不可少的。

随着每个企业的IT系统架构越来越复杂，对所有系统提供统一的管理变得越来越复杂和不可实现。SAP已经适时的推出solution manager支撑整个SAP系统的生命周期管理，但是solution manager对SAP系统的系统信息和SAP组件信息其实依赖于SLD（system landscape direcotry）。SLD相当于一个中央数据信息库，保存了所有企业范围内（按需配置范围）的系统信息和模块信息。比如安装了哪些SAP应用，每个应用的模块的patch level是多少，这样便于对系统进行统一管理。

而SLD的信息是自动更新的，对于ABAP AS是通过RFC，对于JAVA AS是通过HTTP，而对于非SAP系统，因为SLD是基于DMTF标准，所以也提供了API。

另外，整个SLD是基于JAVA开发的。

具体详细的介绍和配置信息，可以参考SDN http://www.sdn.sap.com/irj/sdn/nw-sld

对于SAP Basis顾问来说，应该了解SLD，而且因为在安装过程中，您会被要求注册到已有SDL和创建新的SLD这样一个步骤。

Introducing SAP enhancement packages for SAP ERP
包含一个how to的文档，十分不错

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/8056

Is it possible to relocate an SAP Content Server?

Yes, but you should consider the following points:

• If you want to move an entire SAP Content Server with all its repositories, copy the file ContentServer.ini and the security directory (underneath the ContentServer directory) to the new server. Use the SAP DB backup/restore functionality to copy the contents of the database.
• If the machine name or the HTTP port of the Content Server is changed during relocation, remember to modify the repository definitions in the SAP system accordingly.
• We do not recommend that you just make a physical copy of the old server, as this may create problems with the IIS when you change the IP address, causing the IIS to shut down. If this happens, a simple uninstall does not help. You will have to reinstall NT, the service pack, and the option pack, so please be careful.

note 129352 - Homogeneous system copy with MaxDB (SAP DB) can help for SAP DB backup/restore

Please be aware that SAP only support MaxDB RDBMS so far.

Note 651812 - FAQ: BR*TOOLS and SAPDBA

1. What are BR*TOOLS and SAPDBA?

BR*TOOLS and SAPDBA are utility programs for Oracle administration that are developed by SAP. BR*TOOLS are increasingly replacing SAPDBA functions.

2. What BR*TOOLS are available and what do these do?

• BRBACKUP: Database backup

• BRARCHIVE: Backup of offline redo logs

• BRRESTORE: Restoration (restore) of backups (see Note 605062)

• BRRECOVER: Restore/recovery (Notes 602497, 605062)

• BRSPACE: Reorganizations (see Notes 647697 and 541538)

• BRCONNECT: Various administration tasks (see Note 403704) such as creation of statistics (see Note 588668) or database checks

• BRGUI: Graphical user interface for the BR*TOOLS (Note 611493)

• BRTOOLS: Text-based user interface for the BR*TOOLS

3. Where can I find information about Support Packages, installation and compatibility?

Refer to SAP Note 12741.

4. Which releases of the BR*TOOLS and SAPDBA should be used?

We strongly recommend that you only use Version 6.10 or higher. Only these versions are updated on a regular basis.

5. What do I do if one of the BR*TOOLS or SAPDBA results in an error?

If you cannot find a solution in the SAP notes, you should check whether a current patch for the tool still returns the same error. If so, create a customer message under the component BC-DB-ORA-DBA.

6. How can I find out which release and patch level belong to an installed tool?

Call the tool with the " -V" option (for example, "brconnect -V "). The result includes the following lines with release and patch level:

kernel release <release>
patch level <patchlevel>

7. Which operating system and database users should be used with BR*TOOLS and SAPDBA?

• Operating system users:

• • WINDOWS:

With a manual call, <sid>adm should be used for all tools. If you start from DB13, sapservice<sid> is automatically used.

• • UNIX:

All tools can be started as ora<sid>. The tools that can be called from DB13 (BRBACKUP, BRARCHIVE, BRCONNECT) can alternatively be started as <sid>adm.

• Database user:

• • BR*TOOLS:

The OPS$ user is recommended as the database user ("-u /"), because it does not require a password. Alternatively, you can also use the SYSTEM user (including the password).

One exception is the BRCONNECT function " -f chpass", which can only be used with SYSTEM.

Caution: As of BRCONNECT 6. 40 Support Package 25, you can also work with the OPS$ user ("-u /"). As a prerequisite, BRCONNECT must have been started as the OS users <sid>adm or ora<sid>, which allows the "CONNECT / AS SYSDBA" (because it belongs to the "dba" group).

• • SAPDBA (menu function):

You can only use SYSTEM as the database user.

8. Where do I find the parameter files for the BR*TOOLS and SAPDBA?

The following parameter files exist:

• BR*TOOLS: $ORACLE_HOME/dbs/init<sid>.sap

• SAPDBA: $ORACLE_HOME/dbs/init<sid>.dba

9. Where do I find the log files of the BR*TOOLS and SAPDBA?

Depending on the tool you are using, the log files are located in the following directories ($SAPDATA_HOME = /oracle/<sid>):

• $SAPDATA_HOME/sapbackup: BRBACKUP, BRRESTORE, BRRECOVER

• $SAPDATA_HOME/saparch: BRARCHIVE

• $SAPDATA_HOME/sapcheck: BRCONNECT

• $SAPDATA_HOME/sapreorg: BRSPACE
  
  If you want to use a directory other than the standard directories, you must set the SAPBACKUP, SAPARCH, SAPCHECK or SAPREORG environment variables.
  
  Depending on the action you have executed, SAPDBA log files are also stored in one of these directories.

10. How can I delete old log files of the BR*TOOLS and SAPDBA?

You can delete obsolete log files with the BRCONNECT parameter "-f cleanup". By default, logs that are older than 30 days are deleted. If you want to configure a different time interval, you can use a number of cleanup_* parameters. Refer to the BRCONNECT documentation for further details.

11. How do I recognize errors and warnings in the BR*TOOLS log?

The entries in the log files of the BR*TOOLS start with an abbreviation BR[0-9][0-9][0-9][IWE], that is, with the string "BR", followed by three numbers and one of the letters I, W or E (for example, BR051I or BR310E). The final letter indicates whether the entry represents an information message (I), a warning message (W) or an error message (E).

12. How I can adjust the functions of "brconnect -f next"?

"brconnect -f next" checks whether the NEXT size of objects must be adjusted and performs the adjustment if required. In certain cases, it may be advisable to adjust the standard function (for example, to avoid unnecessarily large NEXT sizes or to exclude certain tables from a check).

An upper limit can be defined for the NEXT size (set by BRCONNECT) with the parameter next_max_size in init<sid>.sap. For example, "next_max_size = 1G" limits the maximum NEXT size to 1 gigabyte.

You can use the parameter next_exclude to specify objects that are to be excluded from the check (for example, next_exclude = SAPR3.T000).

See the BRCONNECT documentation for more configuration options.

13. Why does "brconnect -f check" not record a TABLESPACE_FULL even though a tablespace has already exceeded the threshold value?

With AUTOEXTEND files, BRCONNECT also calculates the space that may be available in the file system. A TABLESPACE_FULL warning is only issued with AUTOEXTEND files if the total of the freespace available in the tablespace and within the framework of AUTOEXTEND exceeds the threshold value.

14. Can I use BRBACKUP even if the database can no longer be started?

In some cases (before you import a restore, for example), it may be advisable to save the current status of the database as a precaution, even if you can no longer open the database properly in the current status. Since it is only possible to use BRBACKUP if the database can be opened, you cannot run a backup with this tool. In this case, you must use other tools for a backup or execute a simple file system backup.

15. What do the return codes of the BR*TOOLS mean?

• Return Code 0: Successful execution

• Return Code 1: Execution with warning(s)

• Return Code 2: Termination in the initialization phase

• Return Code 3: Error in the initialization phase

• Return Code 4: Termination in the execution phase

• Return Code 5: Error in the execution phase

• Return Code 6: Abort

• Return Code 9: In execution

These return codes also correspond to the return codes logged in table SDBAH. Only for return codes 6 and 9 a different SDBAH entry exists: 9999. This 9999 may appear constantly if, for example, a BR*TOOL has been terminated because of an error or if an online backup was only recovered BEFORE the SDBAH update at the end of BRBACKUP.

16. Can I also use the BR*TOOLS for SAP systems that do not have SAP ABAP basis?

Yes, refer to Note 12741 for more information.

To use BRBACKUP, BRARCHIVE and BRRESTORE, see Note 320457.

In the case of MDM, see Note 936665.

As of Version 7. 00, an extended support of BRCONNECT is available (Note 892294).

17. Why does BRBACKUP use CPIO even if TAPE_COPY_COMMAND is set to DD?

DD is only used to backup large files, such as the Oracle data files. Smaller files, such as init<sid>.ora, are always copied with CPIO. Therefore, CPIO must always be installed correctly to avoid errors.

18. What is the importance of the "jid" parameter?

The parameter "-jid" is used to transfer a job identifier, which enables the system to map a BR*TOOLS run to an SAP and DB13 job. This prevents some of the problems described in Note 651452. Otherwise, this parameter alters nothing about the execution of BR*TOOLS.

19. Where can I find more information?

Information about using BR*TOOLS and SAPDBA is available in the SAP online documentation.

Additional information about other important topics is available on SAP Service Marketplace under the quick link "dbaora":

http://service.sap.com/dbaora

Note 1028624

Overview of the new DBA Cockpit

The DBA Cockpit replaces different transactions that were used for monitoring and administration up to now. These include the following transactions in particular, which now branch to individual functions in the DBA Cockpit:

DB13 DBA planning calendar
DB13C Central planning calendar
DB12 Backup logs
DB14 DBA operation logs
ST04 Database Performance Analysis: Oracle database overview
DB02 Database Performance: tables and indices

The transactions listed above continue to be available, but the transaction codes were renamed to <previous transaction code>OLD. This means that the transaction codes are now ST04OLD, DB02OLD, DB12OLD, DB13OLD, DB14OLD, and DB13COLD.

You use transaction DBACOCKPIT to call the DBA Cockpit. The DBA Cockpit has a navigation area that is visible in all the functions of the DBA Cockpit. This area contains a menu tree with the following access points:

- Performance (corresponds to the old transaction ST04)
- Space (corresponds to the old transaction DB02)
- Jobs (corresponds to the old transactions DB13, DB12, DB14, DB13C)
- Diagnostics

The individual functions of the DBA Cockpit are located beneath these four access points. You can call a function by clicking it.

Prerequisites for using the DBA Cockpit:

The prerequisites described here are required for monitoring and administration of the local system (that is, the system on which the DBA Cockpit is running).

• Some performance monitors within the DBA Cockpit require special database objects. These objects are created using an SQL script. See Note 706927 for this script and more information.

• *The new planning calendar requires BR*Tools 700 patch level 24 or higher.

• Some functions in the DBA Cockpit require the Oracle Active Workload Repository. This Oracle option must therefore be available for selection (see Note 1028068).

Additional corrections for the DBA Cockpit with Basis 7.00 Support Package 12 which are only corrected in Support Package 13:

• The correction from Note 1042725 (DB02 Refresh terminates in short dump) needs to be implemented.

• The correction from Note 1046668 (DBA Cockpit->Database->Overview causes a dump) needs to be implemented.

• You must import the transport that is attached to Note 1052909 (Transport_for_NW04s_SP12_only.zip). It corrects various small errors in the system administration and planning calendar.

• Implement the corrections from Note 1076147 (Incorrect status display of backups in planning calendar).

• Implement the corrections from Note 1084949 (DBACOCKPIT: Incorrect status display in Central Calendar).

Additional corrections for the DBA Cockpit with Basis 7.00 Support Package 12 and 13 which are only corrected in Support Package 14:

• Implement the corrections from Note 1081265 (DBACOCKPIT: Backup logs are not displayed).

• Implement the corrections from Note 1076507 (DBACOCKPIT SQL error ORA-942 during access to table DBAD).

• Implement the corrections from Note 1076716 (DBACOCKPIT: RFC connection cannot be entered).

• Implement the corrections from Note 1084146 (Planning calendar: Incorrect selection using list box).

• Implement the corrections from Note 1088211 (DBACOCKPIT: Error when editing planned actions).

• Implement the corrections from Note 1100026 (DBACOCKPIT: Short dump DYNP_TOO_MANY_RADIOBUTTONS_ON).

Additional corrections for the DBA Cockpit with Basis 7.00 Support Package 12, 13, and 14 that are only corrected in Support Package 15:

• Implement the corrections from Note 1110280 (DBACOCKPIT: Incorrect number of redo logs that are not saved).

• Implement the corrections from Note 1108971 (DBACOCKPIT: Overview is incorrect in Central Calendar).

• Implement the corrections from Note 1112726 (DBACOCKPIT: Button 'All' in 'DBA Logs' does not display data). This error occurs with Support Package 13 and Support Package 14 but not with Support Package 12.

• Implement the corrections from Note 1113261 (DBA Cockpit: Incorrect display of external jobs in DB13).

• Implement the corrections from Note 1107729 (DBACOCKPIT: Action list in planning calendar is incorrect).

• Implement the corrections from Note 1134253 (DBACOCKPIT: Display error in external BRCONNECT actions).

Additional corrections for DBA Cockpit with Basis 7.00 Support Package 12, 13, 14, and 15 that are corrected only in Support Package 16:

• Implement the corrections from Note 1142791 (Planning calendar: Incorrect status in the daily overview).

• Implement the corrections from Note 1139787 (Planning calendar: Option for profile in "Verify DB" missing).

• Implement the corrections from Note 1164574 (Planning calendar: db_error for action 'Cleanup').

• Implement the corrections from Note 1164986 (DBA Cockpit: Incorrect status of periodically scheduled jobs).

Additional corrections for DBA Cockpit with Basis 7.00 Support Package 12, 13, 14, 15 and 16 that are corrected only in Support Package 17:

• Implement the corrections from Note 1166977 (DBACOCKPIT: Display error for backups with redo log).

Further corrections that you may have to implement in remote systems (ABAP) that are connected to the DBA Cockpit:

• Implement the corrections from Note 1088975 (Short dump COMPUTE_INT_ZERODEVIDE in DB13).

• Implement the corrections from Note 1077188 (DBACOCKPIT: RFC for remote systems cannot be configured).

• Implement the correction from Note 1093883 (ORACLE: Function module DB6_PLAN_ADD_BATCH failed) in remote systems with Basis Release 640 if you want to use the planning calendar in the DBA Cockpit for these systems.

New planning calendar

(Transaction DB13 or Jobs -> DBA Planning Calendar in the DBA Cockpit menu tree)

The planning calendar previously used was replaced with the new calendar to meet legal requirements regarding the accessibility of screen programs.

The previously used planning calendar is still available in transaction DB13OLD. Completed actions are visible in both the old and new planning calendars. Actions that were scheduled in the old planning calendar also appear as scheduled in the new calendar. The reverse also applies: Actions that you have scheduled in the new planning calendar are also visible in the old calendar. However, there is one exception:

Periodically scheduled actions in the new planning calendar with a repetition period other than weekly (for example, hourly or daily) are not displayed in the old planning calendar.

This can lead to problems if the old and new planning calendar are used in parallel. We therefore advise against using both planning calendars at the same time.

Even if the old calendar is still usable, it now has the status "deprecated". For this reason, we recommend that you switch to the new calendar in the medium term, provided that you do not need to use it right away.

For more information about the new planning calendar, especially about the configuration and administration of external databases, see Note 1025707 and the documentation.

New central planning calendar

(Transaction DB13C or Jobs -> Central Calendar in the DBA Cockpit menu tree)

The new central planning calendar differs from the old planning calendar by having a different configuration for systems that are to be monitored. The old planning calendar is still available under transaction DB13COLD. The new central planning calendar uses the system configuration of the DBA Cockpit to add or remove systems.

To migrate the systems of the old central planning calendar to the new planning calendar, choose Administration -> Migration DB13C Configuration in the new central planning calendar.

New transaction DB02 (Space)
(Transaction DB02 -> Space in the DBA Cockpit menu tree)

Refer to Note 868063 and also to Note 1002840 if required.

Administration and monitoring of external databases

A feature of the DBA Cockpit is that you can monitor and administer external databases. This applies to both ABAP and non-ABAP systems.

Oracle databases and all other database systems supported by SAP can be connected as external databases. If you want to connect non-Oracle databases, the relevant database client software and the SAP database shared library must be installed.
(In this note, we assume that the system on which the DBA Cockpit is running is an Oracle database system. If this is not the case, but you intend to connect external Oracle databases, you must first install the Oracle database client software and the corresponding SAP database shared library.)

External Oracle databases are only supported as of Version 9.2.

If you need to connect external Unicode databases, the system on which the DBA Cockpit is running must be a Unicode system.

The connection of external databases requires a working secondary database connection; that is, there must be an entry in the DBCON table. When you add an external database in the system configuration of the DBA Cockpit, you can create a DBCON entry directly. The database user who is to be entered for the database connection must be the relevant schema owner, in other words, SAPR3, SAP<SID>, SAPSR3 or SAPDB<SID>. In MCOD systems, you must choose the database user who is the owner of the tables SDBAH and SDBAD.

Before you connect an external Oracle database, the following requirements must be met:

1. The script from Note 706927 must be executed on the external Oracle database.

2. For the planning calendar (DB13) and the related transactions DB12 and DB14, you also need to configure either an RFC ABAP connection (only allowed for external ABAP systems) or a connection through SAP gateway or a remote shell. For more information, see Note 1025707.

3. In addition, at least BR*Tools 700 patch level 24 (Oracle client 10) or BR*Tools 640 patch level 42 (Oracle client 9) must be installed on the external system.

4. You should ensure the system time does not differentiate between the remote system and the system, on which the DBA cockpit runs. The deviation must not be longer that 60 seconds under any circumstance.

根据Note 455140配置好SAPConnect收发email以后，如果发现没法正常工作，可以参考note 607108

但是不知何故，做收email直接telnet到服务器那段怎么做都是554错误。

根据SDN相似错误，SICF配置service时那个用户，权限付SAP_ALL telnet操作就成功了

但是估计这个不是最终解决方案 有个SAP_ALL在系统里，总是让人寝食难难的...

https://forums.sdn.sap.com/message.jspa?messageID=7310724

可能出问题的领域

1. Database
2. Network
3. Resource( memory etc...)
4. Kernel

从客户处获取system log/dev_ms/dev_disp/dev_w*以及数据库log

http://help.sap.com/saphelp_sm32/helpdata/EN/b3/023a4227deb16be10000000a155106/frameset.htm

http://www.saptechies.com/step-by-step-procedure-to-generate-solution-manager-key-smsy-solution-manager-40/

http://it.toolbox.com/wiki/index.php/Generate_a_Solution_Manager_Key_with_T-code_SMSY_for_SAP_ECC_5.0_version_onwards

https://www.sdn.sap.com/irj/scn/message?messageID=6137442

Just delete old license key.

Choose old license key and click right button, select delete.