|
BlueSystemCopy - FAQ
Starten eines Kopierauftrags
-
Wenn ich versuche, einen Kopierauftrag zu starten, bekomme ich immer sofort eine Fehlermeldung (Popup), die besagt, dass eine XML Datei nicht existiert oder dass ein Shell Kommando nicht ausgeführt werden konnte.
-
Sofort nach dem Starten eines Auftrags kommt: libcrypt.so.0.9.8/libcrypto.so.0.9.8: not found. Sie nutzen RedHat als BlueSystemCopy Server.
Lizenzdateien
-
Wie beantrage ich eine Lizenz und welche Daten benötigen sie dazu von mir? Das Excel-Formular gibt's hier!
-
Wohin muss die Lizenz-Datei??
-
Warum funktioniert meine Lizenzdatei nicht mehr?
-
Warum funktioniert meine Lizenzdatei nicht, obwohl ich die richtige Datei verwende?
Oracle-spezifische Probleme
-
ORA-00600 bzw. gleichzeitig der BSC-Fehler 02300E tritt beim Erzeugen des Controlfiles direkt nach der Kopie oder dem Restore der Datenfiles auf.
DB2-spezifische Probleme
-
Warum dauert das Umbenennen einzelner Tablespaces nach einer Kopie auf DB2 extrem lange (über eine Stunde oder noch länger)?
Experten-Optionen
-
Kann man zwischen zwei Systemen mit unterschiedlichen Schemata kopieren? BlueSystemCopy meldet während des Checklaufs einen Fehler deswegen.
-
Kann man zwischen zwei Systemen mit unterschiedlichen DB-Releases kopieren? BlueSystemCopy meldet während des Checklaufs einen Fehler deswegen.
-
Kann man zwischen zwei Systemen mit unterschiedlichen SAP Kernel Ständen kopieren? BlueSystemCopy meldet während des Checklaufs einen Fehler deswegen.
Ältere Versionen von BlueSystemCopy (< V6.x)
-
Ich bekomme immer sofort eine Fehlermeldung (Popup), wenn ich versuche, einen Kopierauftrag zu starten. Es hat noch nie geklappt!
-
Sofort nach dem Starten eines Auftrags kommt: /basis/bin/bscc: arg list too long
Starten eines Kopierauftrags
Q:
|
Wenn ich versuche, einen Kopierauftrag zu starten, bekomme ich immer sofort eine Fehlermeldung (Popup), die besagt, dass eine XML Datei nicht existiert oder dass ein Shell Kommando nicht ausgeführt werden konnte.
|
A:
|
Sie haben kürzlich auf die Version 2.x des GUIs upgedated und verwenden den neuen Servermodus (mit Anmeldung).
Und Sie verwenden die csh als Login-Shell für den Benutzer auf dem BlueSystemCopy-Server.
Bitte verwenden Sie bis auf weiteres nicht die csh für den Benutzer auf dem BlueSystemCopy-Server. Es handelt sich üblicherweise um den Benutzer syscopy (falls Sie exakt unserer Empfehlung gefolgt sind). Falls das nicht möglich sein sollte, verwenden Sie das GUI bitte im Kompatibilitätsmodus.
|
Details zum Fehlerbild:
Error reading XML file '/basis/client/jobs/bsc_3b687d97-a546-487b-8bf4-1240064a81c5.xml':
The following error occured while executing a shell command.:
File '/basis/client/jobs/bsc_3b687d97-a546-487b-8bf4-1240064a81c5.xml' does not exist.

Q:
|
Sofort nach dem Starten eines Auftrags kommt: libcrypt.so.0.9.8/libcrypto.so.0.9.8: not found. Sie nutzen RedHat als BlueSystemCopy Server.
|
A:
|
Am besten updaten Sie Ihren BlueSystemCopy Server auf eine Version größer-gleich 6.3! Ab dieser Version benötigen Sie nur mehr das openssl-Binary und keine shared Linraries. Ein Update auf V6.3 oder höher ist u.a. daher dringend empfohlen!
Die folgende Lösung ist daher nur für Versionen kleiner als V6.3 nötig:
Redhat liefert nur ein sehr verkrüppeltes, eigenes openssl mit, das nicht die Standard openssl-Libraries hat (siehe
http://openssl.org/support/faq.html#BUILD8 "What is special about OpenSSL on Redhat?").
Abhilfe:
1) cd /usr/lib
2) ls -l libcrypt*
(existieren die Dateien libcrypt.so und libcrypto.so ?
Wenn nein, dann Installieren per:
3a) yum install openssl-devel.i386
Bzw.
3b) rpm das Paket openssl-devel-0.9.8b-10.el5_2.1
(Stand 2/2009 bzw. das dann aktuelle Paket)
4) ln -s libcrypt.so libcrypt.so.0.9.8
ln -s libcrypto.so libcrypto.so.0.9.8
|

Lizenzdateien
Q:
|
Wie beantrage ich eine Lizenz und welche Daten benötigen sie dazu von mir?
|
A:
|
Am einfachsten und schnellsten geht es per Mail an unseren Support und mit dem vorbereiteten Excel-Formular.
Folgende Angaben sind für den Key erforderlich:
- SID des Quellsystems
- Hostname der Quell-Datenbankservers, wie er vom BlueSystemCopy Server aus genannt wird.
- Betriebssystem und -Version des Datenbankservers
- Datenbanktyp (ORA, DB2, MSS)
- Installationsnummer des Quellsystems
Mit folgenden Angaben erleichtern Sie es uns und sich selbst, damit wir Ihnen im Fall des Falles schnell und zielgerichtet helfen können:
- Datenbankversion
- Art des SAP Systems (ERP, BW/BI, HR, ...)
- Typ des Systems (ABAP only, DoubleStack, JavaOnly)
- SAP-Basis-Version (WebAS, s. Support Package SAP_BASIS)
- Falls abweichend von "erforderlich 3.": Betriebssystem und -Version der Zentralinstanz (ZI)
- Betriebssystem und -Version des BlueSystemCopy Servers
- Hostname des BlueSystemCopy Servers
|

Q:
|
Wohin muss die Lizenz-Datei??
|
A:
|
Die folgenden Angaben werden relativ zum sogenannten Basis-Verzeichnis gemacht. Dieses ist das Verzeichnis auf dem BlueSystemCopy Server, das Sie bei der Installation angegeben haben und unterhalb dessen u.a. folgende Unterverzeichnisse angelegt werden:
- <basis>/bin => für Binaries
- <basis>/wrk => für Arbeits-Dateien (Work-Dateien)
Wo die Lizenzdateien gefunden werden, ist abhängig von der Version des BlueSystemCopy Servers:
BlueSystemCopy Server 6.x
Hier müssen die Lizenzdateien im Unterverzeichnis "etc" des Basis-Verzeichnisses abgelegt werden.
Beispiel:
Das bscc-Executable ist in "/usr/sap/bsc/bin" installiert. Dann müssen die Lizenzdateien unter "/usr/sap/bsc/etc" abgelegt werden.
BlueSystemCopy 5.x
Hier werden die Lizenzdateien in beliebigen Unterverzeichnissen (auch mehrere Ebenen) des Basis-Verzeichnisses gefunden.
|

Q:
|
Warum funktioniert meine Lizenzdatei nicht mehr?
|
A:
|
Wenn Sie auf Version 6.x upgedated haben, funktionieren die alten Lizenzdateien leider nicht mehr. Aus technischen Gründen enthalten die Lizenzdateien nun auch den Hostnamen.
Wenn Sie einen gültigen Support-Vertrag haben, erhalten Sie von uns eine neue Datei, wenn
- Sie noch eine alte V5.x-Lizenzdatei haben oder
- Sie das SAP System auf einen anderen Rechner umziehen
Bitte wenden Sie sich an unseren Support!
Möglicherweise ist die Lizenzdatei auch einfach abgelaufen (expired).
|

Q:
|
Warum funktioniert meine Lizenzdatei nicht, obwohl ich die richtige Datei verwende?
Wenn Sie bei dieser Antwort gelandet sind, haben Sie wahrscheinlich noch BlueSystemCopy 5.x im Einsatz. Bei BlueSystemCopy 6.x tritt das Problem nämlich nicht mehr auf.
|
A:
|
Bitte beachten, dass die Dateien nur funktionieren, wenn sie im UNIX-Format vorliegen (0A als Zeilenende, nicht 0D0A). Das betrifft auch Windows!
Die Datei könnte z.B. bei folgenden Vorgängen verändert worden sein:
- Möglicherweise wurde die Datei über die Zwischenablage kopiert.
- Die Datei wird beim ftp- oder sftp-Transfer auf den Server automatisch konvertiert
- Ein Virenscanner hat den Anhang der Mail gescannt und dabei die Unix-Linefeeds durch Windows-Linefeeds ersetzt
|

Oracle-spezifische Probleme
Q:
|
ORA-00600 bzw. gleichzeitig der BSC-Fehler 02300E tritt beim Erzeugen des Controlfiles direkt nach der Kopie oder dem Restore der Datenfiles auf.
|
A:
|
Es handelt sich um den Oracle Bug 4877360 (oder zumindest mit den gleichen Symptomen).
Ein möglicher Workaround besteht darin, das Controlfile-Skript mit einer maxloghistory von 65535 oder kleiner auszuführen. Das Skript hat BlueSystemCopy auf dem Zielsystem in das entsprechende Workdir (z.B. /basis/wrk/bscprl_<unique-job-id> gelegt. Modifizieren Sie dort einfach den o.g. Wert in der Datei create_control.sql und re-starten Sie den BlueSystemCopy-Auftrag.
Weitere Details siehe auch Oracle MetaLink Note 1012929.6: How to Recreate the Controlfile oder Note 360962.1 Manual Completion of a Failed RMAN Duplicate (Phase 2).
|
Details zum Fehlerbild:
CREATE CONTROLFILE REUSE SET DATABASE "GTQ" RESETLOGS ARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-00600: internal error code, arguments: [kccscf_1], [9], [74752], [65535],
[], [], [], []
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning and Data Mining options
BSC -02300E-20100203 104851 CREATE_CONTROL.SQL gescheitert !!! => EXIT

DB2-spezifische Probleme
Q:
|
Warum dauert das Umbenennen einzelner Tablespaces nach einer Kopie auf DB2 extrem lange (über eine Stunde oder noch länger)?
|
A:
|
Evtl. ist eine Speichereinstellung der Datenbank für die Umbenennung zu klein.
Bitte prüfen Sie den Parameter CATALOGCACHE_SZ und erhöhen Sie diesen gegebenenfalls.
Der Parameter kann problemlos z.B. auf 25600 (*4k) erhöht werden.
|

Experten-Optionen
Q:
|
Kann man zwischen zwei Systemen mit unterschiedlichen Schemata kopieren? BlueSystemCopy meldet während des Checklaufs einen Fehler deswegen.
|
A:
|
Ja, mit zusätzlichen manuellen Tätigkeiten geht das. Zuerst müssen Sie den Expertenschalter SCHEMACHECK=no setzten, damit BlueSystemCopy keinen Fehler, sondern nur eine Warnung wegen des Schemas ausgibt.
Am einfachsten ist es beim ABAP-Stack: Hier geht es nur um die Environment-Variable dbs_ora_schema bzw. dbs_db2_schema. Am saubersten in BEIDEN Environments, also <sid>adm und ora<sid>.
Bei DB2 muss man zusätzlich noch den "OS-Connect-Benutzer" anlegen (meist sap<srcsid>) und per dscdb6up -create <connect_user_password> <sidadm_password> hinterlegen. Sie finden Details zur (nicht unterstützten) Schema Umbenennung auch im SAP Hinweis 713524 "DB6: Zusatzinformationen zur Systemkopie mit DB Mitteln".
Bei einem Java-(Double)Stack muss man den neuen Schema-Benutzer des Quellsystems im SecStore eintragen. Dies geht mit dem ConfigTool, auch wenn das ConfigTool selbst nicht an die Datenbank heran kommt (weil ihm auch der User/das Passwort fehlt). Das funktioniert, weil der SecStore in einer verschlüsselten Datei liegt.
|

Q:
|
Kann man zwischen zwei Systemen mit unterschiedlichen DB-Releases kopieren? BlueSystemCopy meldet während des Checklaufs einen Fehler deswegen.
|
A:
|
Ja, das geht mit dem Expertenschalter DBVERCHECK=no. Bei V5.x hieß der Parameter noch ORAVERSCHECK=no. Dadurch meldet BlueSystemCopy nur eine Warnung statt eines Fehlers.
Bitte beachten Sie, dass es dann in Ihrer Verantwortung liegt, dass die Ziel-Datenbank trotzdem korrekt läuft (z.B. unter Oracle mittels dbua oder catalog-/catproc-Skripten, je nach Art des Versionsunterschieds).
|

Q:
|
Kann man zwischen zwei Systemen mit unterschiedlichen SAP Kernel Ständen kopieren? BlueSystemCopy meldet während des Checklaufs einen Fehler deswegen.
|
A:
|
Von einem neueren Patchlevel auf einen älteren geht es leider nicht. Es gibt hier keinen Expertenschalter. Grund ist, dass ein zu kleiner Kernelstand des Zielsystems dieses völlig unbrauchbar machen kann: Das Format der ABAP Loads ändert sich von Zeit zu Zeit. Die Loads werden aber vom Quellsystem mitkopiert. Das Zielsystem kompiliert diese nicht neu, weil sie schon existieren, kann aber andererseits auch nichts mit dem neuen Format anfangen. Folge ist, dass nicht einmal der Login-Bildschirm angezeigt werden kann. Weitere Details siehe OSS Hinweis
Kein Problem ist es, wenn das Zielsystem einen neueren Patchlevel hat als das Quellsystem.
|

Ältere Versionen von BlueSystemCopy (< V6.x)
Q:
|
Ich bekomme immer sofort eine Fehlermeldung (Popup), wenn ich versuche, einen Kopierauftrag zu starten. Es hat noch nie geklappt!
|
A:
|
Zu 90 % liegt es an einem noch nicht in der Registry eingetragenen known_hosts Fingerabdruck. Diesen einzutragen, ist sehr einfach:
1x eine Verbindung mit PuTTY (NICHT: PuTTY portable!) zum BlueSystemCopy-Server aufbauen und den Fingerabdruck des Servers bestätigen. Wenn Sie den exakt gleichen Namen bzw. IP-Adresse eintragen, den Sie auch in den Verbindungsdaten verwenden, klappt der Aufbau künftig.
Wenn dies nicht die Ursache sein sollte, sind folgende weitere Ursachen denkbar:
- Timeout wegen
a) ssh reverse lookups
b) Infrastruktur
- Falscher/s User/passwort
- Falsche IP/Hostname
- HP-UX: Unverträglichkeit mit putty 0.60. Workaround: putty 0.57 oder Fix für HP-UX einspielen.
|

Q:
|
Sofort nach dem Starten eines Auftrags kommt: /basis/bin/bscc: arg list too long
|
A:
|
Dieser Fehler tritt nur auf AIX auf und nur bei BlueSystemCopy Server < V6.x
Das limit auf AIX 5.x kann direkt geändert werden mit:
chdev -l sys0 -a ncargs=<Wert>
<Wert> muss im Bereich von 6x 4KB bis 1024x 4 KB liegen
(Quelle: Ian Northeast in comp.unix.aix oder AIX Online Documentation.)
<Wert> sollte für BlueSystemCopy 32 betragen (= 128k).
Der Wert wird sofort mit obigem Befehl wirksam und bleibt auch nach Reboots erhalten.
|

Zurück zu Empirius.de
| Support Startseite
| Dokumentation
| Download
|