DDIC SystemCopy Password

Trong vài tình huống, biết đâu cần ...

1. Update Directly

SOURCE SYSTEM

SELECT PASSCODE FROM SAPSR3.USR02 WHERE BNAME='DDIC' AND MANDT='xxx';

Copy the known PASSCODE

TARGET SYSTEM.

UPDATE SAPSR3.USR02 SET PASSCODE='value of passcode' WHERE BNAME='DDIC' AND MANDT='xxx'

2. Dummy, continue and change later

- Give a dummy pass for DDIC in the Parameter phase
- When error appears in the end of installation, logon to SAP with other ID such as SAP* (maybe check parameter sapstar)
- Logon ok then Change the DDIC pass to the dummy in the parameter phase
- Continue with installer

WSAECONNRESET - SAP GUI

rdisp/keepalive giảm bớt để khắc phục lỗi 10054 - WSAECONNRESET

Change TR after released

Cái report này cũng hay hay, có thể change vài thứ, kể cả status của TR.

RDDIT076

Đôi khi có vài trường hợp cần TR trở lại trạng thái chưa Release để làm một số việc khác...

SUM2SP3 - Internal error occurred. Press F5 to restore the session.

Cùng Server, cùng Browser, Path vẫn còn đó mà SP3 báo lỗi như hình sau - Mất mấy ngày Searching, thay đổi tùm lum vẫn không giải quyết được - nay tự nhiên SAP shows 1 cái note đã có cách đây 1 tháng (?!?)

Nội dung bảo là "This error occurs when you have lowercase letters for the SID in the SUM URL."

Choáng!!!

Và cái Note cho chính xác vấn đề:
2681867 - Detailed Message : Message from service : Missing 'diagtime' in dialog answer

SLD -> LMDB -> SAP Support Portal

1 Server, setup lặp lại vài lần nhiều hệ thống SAP ERP cùng SID....=> Cái LMDB nó update loạn cả lên...

Mất vài ngày để đồng bộ lại: SLD ==> LMDB ==> SAP Support Portal ==> để sử dụng được các tiện ích như MP

Một số Notes/Jobs/Reports...

-1891566; 1962139; 1939864;1784080...

SAP_LMDB_LDB_0000000001
LANDSCAPE FETCH
REFRESH_ADMIN_DATA_FROM_SUPPORT

Chú ý một số Jobs nếu check thấy chạy thành công (Green) nhưng xem Log nó báo lỗi trong đó

Some Problems with STMS - Local Change Requests

Mọi chuyện xuất phát từ việc Apply cái SAP Note vào 1 SAP System (single, no transport route) và có tạo số TR và release, tuy nhiên không thể release ra ngoài OS để có thể copy sang system khác (do nó là "Local Change Requests")


==>Vài thứ linh tinh liên quan đến vấn đề Transport Requests

1. Report RDDIT076 dùng để Un-Released 1 TR

2. Ở SE01, có thể  Change được Target systems (nếu đã Release thì dùng bước 1 trên mới được); tuy nhiên vấn đề là không có cấu hình system nào khác

3. Vậy vào Client 000, cấu hình lại STMS, thêm 1 Virtual system và tạo Consolidate Route là xong. Tuy nhiên có thể các TR đã tạo rồi không được liên kết nên vẫn không thể change Target system hay Released ra ngoài OS.

4. Cách đơn giãn nhất là Tạo mới 1 TR dạng "Transport of copies", điền cái Target system là cái Virtual ở trên, xong double click TR mới tạo, chuyển qua Modified và chọn Menu "Include Objects" -> và chọn (nhập) cái TR cũ là xong

==>Cái Transport of copies lưu ý là không có TRs con bên trong (in my case), released and it shows in OS

Blahblah

PREP_PRE_CHECK/SAPMCHK_INI - SUM on SOLMAN

Thực hiện Upgrade Solution Manager (dual stack) from 7.1 to 72

Cái tội không thực hiện check: License, Transport Domain, Processes, Background jobs...

Nên bị lỗi thế này đây

Sau đó thì nhập password nào cũng không được cho user SDM

==>Làm theo link sau để Reset password

https://wiki.scn.sap.com/wiki/display/EP/Reset+SDM+Password+in+Unix+and+Windows+Environment

Take a long time to refresh a import queue (STMS)

Sau vài năm vận hành, update, upgrade, copy... thì cái Transport Landscape của mình nó cũng có nhiều thay đổi và 1 vài system (QAS/PRD) chạy chậm hẳn mỗi khi Refresh Queue hoặc Import TR.

Việc này có nhiều nguyên nhân và cách khắc phục như liệt kê dưới đây, tùy từng ngữ cảnh cụ thể của mỗi Landscape mà ứng dụng (hiểu rõ transport landscape)

- Nên giữ transport Queue ngắn (thường thì policy công ty là transport riêng lẽ từng TR và giữ lại để có thể Re-Import nên cái Queue sẽ ngày càng dài và gây chậm). Nên chọn (F6) và xóa bớt Queue (việc này chỉ update file buffer, không xóa nên file này không giảm size)

- Các folder / file trong DIR_TRANS nếu có size lớn quá cũng ảnh hưởng (theo 1 SAP Note nào đó) và việc này có thể Clean bớt các files cũ đi - Các file cũ (old aged) bị xóa dựa theo bộ tham số sau (Tính bằng ngày - day):

DATALIFETIME=200
OLDDATALIFETIME=365
COFILELIFETIME=365
LOGLIFETIME=200
TMPLIFETIME=365

Cá nhân mình thấy bộ tham số này cần thay đổi chút cho phù hợp

Thực hiện xóa các file vật lý này bằng lệnh tp cleanold như SNote sau

41732 - Deletion of data in transport directory

Tuy nhiên, như đã trãi nghiệm, việc này mang tính dọn dẹp là chủ yếu, không tăng tốc STMS được bao nhiêu.

Theo kinh nghiệm đã làm, việc giảm bớt số lượng Queue và giữ Size của Buffer nhỏ mới tăng tốc được khi Import TR. Xem SNote sau:

1924741 - It takes a long time to refresh a system's import queue

Vấn đề mình gặp phải là:
Cái Buffer của mình nó nằm Local và được Update mỗi khi thực hiện transport actions; trong khi chạy TP CLEANBUFFER <SID> thì nó lại clean cái File Buffer nằm ở Transport Domain. Sau khi phát hiện việc này thì giải pháp là Hoán đổi chúng (backup trước nhé) và Clean và lại hoán đổi. Cuối cùng thì STMS chạy nhanh trở lại. Chỉ còn chậm ở khâu Check Component Version - Việc này có thể Skip nếu thay đổi tham số SP_TRANS_SYNC như trong SNote 1742547 - Information about component version check in TMS; tuy nhiên việc này có thể không cần thiết và chấp nhận chút time này

Blahblah, trãi qua 1 tuần theo dõi từ lúc TR Release ở DEV đến PRD imported, xem các thay đổi ở Trans files vật lý và thực hiện các thao tác như SAP Notes, cuối cùng STMS của mình cũng chạy nhanh trở lại mà không mất Queue

- Lưu ý là nếu bạn làm theo kiểu cực đoan ép buộc, tức vào Xóa (backup, rename... first) file Buffer thì cũng được, STMS sẽ tạo lại file Buffer nhưng bạn bị mất hết Queues, kể cả các Queue chưa được imported)