CSA: Verwalten und Überwachen von
Classic PPM
(nur On-Premise)

ccppmop1581
Verwenden Sie CSA, um Dienste zu starten und zu beenden, Serverports zu öffnen, IGMP-Snooping zu deaktivieren, Statusberichte auszuführen, Protokolldateien zu überprüfen, Ihre
Classic PPM
-Installation zu sichern und wiederherzustellen, Oracle-Datenbankobjekte zu kompilieren, die Größe des Dateiverzeichnisses festzulegen und GEL-Tag-Einschränkungen festzulegen.
2
Starten und Anhalten von Diensten
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Klicken Sie auf Startseite, Alle Dienste.
  3. Aktivieren Sie die Kontrollkästchen neben den Diensten, die Sie starten oder anhalten möchten.
  4. Um die Dienste zu starten, klicken Sie auf "Anfang".
  5. Um die Dienste zu beenden, klicken Sie auf "Anhalten".
Öffnen von Serverports
Classic PPM
benötigt für die Kommunikation zwischen Client und Server sowie Server und Server mehrere offene Netzwerkports. Häufig sind Ports standardmäßig geschlossen oder aus Sicherheitsgründen durch Firewalls blockiert. Alle während der Installation oder Konfiguration ausgewählten Ports müssen offen sein.
Öffnen Sie die erforderlichen Ports unter Bezugnahme auf die Dokumentation für Ihr Betriebssystem bzw. Ihre Firewall. Im nachfolgenden Abschnitt sind der Standardwert, der Typ und eine Beschreibung für alle in
Classic PPM
verwendeten Ports aufgelistet.
In UNIX-Systemen sind Portnummern unter 1024 in der Regel für den Root-Benutzer reserviert.
Best Practice
: Wenn Sie eine Software-Firewall verwenden, geben Sie eine Ausnahme auf der Ebene der ausführbaren Datei statt auf Portebene an. Durch diese Aktion wird sichergestellt, dass die dynamischen Ports, die zugeordnet werden, für die richtige Multicast-Kommunikation geöffnet sind. Weitere Informationen finden Sie unter den
flüchtigen Ports
in der folgenden Liste.
  • 80 oder 443
    Gibt die HTTP- oder HTTPS-Portnummer an, die vom standardmäßigen
    Classic PPM
    -Anwendungsdienst (app) verwendet wird.
    Typ:
    Client zu
    Classic PPM
    -Anwendungsserver
  • 8090
    (Nur für Apache Tomcat-Anwendungsserver) Gibt die HTTP-Port-Nummer an, die von CSA verwendet wird.
    Typ
    : Client zu
    Classic PPM
    -Anwendungsserver
  • 1433 (MS-SQL) oder 1521 (Oracle)
    Definiert die JDBC-Port-Nummer, die für die Kommunikation mit der Datenbank verwendet wird.
    Typ:
    Server zu Datenbankserver
  • 23791
    (Nur Apache Tomcat-Anwendungsserver) Gibt die RMI-Portnummer an, die vom
    Classic PPM
    -Anwendungsdienst (app) verwendet wird.
    Typ:
    Server zu
    Classic PPM
    -Anwendungsserver
  • 23792
    (Nur für Apache Tomcat-Anwendungsserver) Definiert die RMI-Portnummer, die von CSA verwendet wird.
    Typ:
    Server zu
    Classic PPM
    -Anwendungsserver
  • 9090
    Definiert die Multicast-Port-Nummer, die von CSA verwendet wird.
    Typ:
    Server zu
    Classic PPM
    -Anwendungsserver
  • 9091
    Gibt die RMI-Portnummer an, die vom Beacon-Dienst verwendet wird.
    Typ
    : Server zu Server
  • Flüchtige Ports
    Definiert den flüchtigen (kurzlebigen) Portbereich. Für alle Betriebssysteme ist ein flüchtiger Portbereich standardmäßig angegeben. Der herkömmliche BSD-Bereich liegt zwischen 1024 und 4999, obwohl die IANA einen Bereich von 49152 bis 65535 vorschlägt. Der Bereich ist je nach Betriebssystem unterschiedlich und kann deaktiviert werden. Sie können in
    Classic PPM
    beliebige Bereichswerte verwenden. Allerdings müssen Sie einen Bereich aktivieren. Dieser Port ist hauptsächlich für das Funktionieren von Multicast erforderlich.
    Typ:
    Server zu Server
IGMP Snooping
Damit Multicast-Datenverkehr ordnungsgemäß mit Cisco Catalyst Ethernet-Switches übertragen wird, deaktivieren Sie IGMP Snooping (oder aktivieren Sie sowohl IGMP Snooping als auch IGMP Queries) für das VLAN, dem die
Classic PPM
-Server angehören. In der Vergangenheit wurde IP-Multicast sehr ähnlich wie IP-Broadcast gehandhabt, was zu massivem Multicast-Datenverkehr durch Ethernet-Switches an allen Schnittstellen führte. Standardmäßig gilt für Cisco Catalyst-Switches die entgegengesetzte Vorgehensweise, sodass der Multicast-Datenverkehr nicht an alle Schnittstellen geflutet wird.
Mithilfe von IGMP Snooping können Schicht 2-Switches intelligente Multicast-Sendungsentscheidungen treffen, indem der Inhalt jedes IP-Headers der Frame-Schicht 3 untersucht wird. Der Switch verwaltet eine Multicast-Gruppenliste, sodass nur Multicast-Pakete an Schnittstellen gesendet werden, die zu einer bestimmten Gruppe gehören.
Ausführen von Statusberichten
Die Legacy-Registerkarten, -Schaltflächen und -Optionen des CSA-Zustandsberichts wurden in Version 15.3 entfernt. Weitere Informationen finden Sie unter Ausführen eines Statusberichts.
Überprüfen von Protokolldateien
Überprüfen Sie bei Installations-, Upgrade- oder Verwendungsproblemen die Protokolldateien, um eine Erklärung für das Problem zu finden. Standardmäßig schreibt
Classic PPM
nur Fehlermeldungen in die Protokolldateien. Wenn Sie bei der Lösung eines Problems vom technischen Support von CA unterstützt werden, werden Sie möglicherweise dazu aufgefordert, das System für die Anzeige detaillierter Debug-Meldungen zu konfigurieren. Die Protokolldateien werden standardmäßig im Protokollverzeichnis unter dem
Classic PPM
-Basisverzeichnis gespeichert. Jeder Server verfügt über ein eigenes Protokollverzeichnis. Sie können in CSA auch ein anderes Protokollverzeichnis auswählen.
Zum Anzeigen der Protokolldateien kann ein Texteditor verwendet werden. Bei einem
Classic PPM
-Servercluster beziehen sich die Protokolldateien für jeden Server nur auf den entsprechenden Server. Sie können die Protokolle so konfigurieren, dass ausführlichere Details hinzugefügt oder Einträge aktualisiert oder entfernt werden. Die Konfigurationsänderungen der Protokolldatei können sofort in Kraft treten. Andernfalls werden sie erst wirksam, nachdem Sie den
Classic PPM
-Anwendungsdienst (app) und den
Classic PPM
-Hintergrunddienst (bg) neu gestartet haben.
Folgende Tabelle enthält die Liste der standardmäßigen und allgemeinen Protokolldateien. Für jedes Protokoll werden Dateiname, Format und Inhalt aufgelistet.
Jede geklonte Instanz eines Dienstes verfügt über eigene Protokolldateien. Zum Beispiel haben app2, bg3 usw. übereinstimmende Protokolldateien, die durch die ID dargestellt werden. Die erste app- und bg-Instanz haben keine ID.
Protokolldateiname
Format
Inhalte
admin.log
Nur-Text
Eine Aufzeichnung der administrativen Aktivitäten. Diese Aktivitäten werden über den Befehl
admin
oder über einen entsprechenden CSA-Vorgang gesteuert.
app{id}-access-{date}.log
Nur-Text
Sitzungsaktivität (http/s-Anforderungen) für den Vordergrunddienst.
app{id}-bootstrap-ca.log
Nur-Text
ODF-Bootstrap-Aktivitäten, die in der Regel während eines Upgrade- und Patch-Vorgangs auftreten.
app{id}-ca.log
Nur-Text
Das primäre Protokoll für alle Aktivitäten im Vordergrunddienst.
app{id}-dwh.log
Nur-Text
Data Warehouse-spezifische Aktivitäten im Vordergrunddienst.
app{id}-process-engine.log
Nur-Text
Ereignisse, die über den Monitor der Prozess-Engine im Vordergrunddienst aufgezeichnet werden.
app{id}-system.log
Nur-Text
Ausgabe auf Systemebene, die direkt in die Konsole (STDOUT) für den Vordergrunddienst geschrieben wird. Bei dieser Ausgabe handelt es sich in der Regel um Dienststart- oder BS-Meldungen.
beacon-system.log
Nur-Text
Ausgabe auf Systemebene, die direkt in die Konsole (STDOUT) für den Beacon-Dienst geschrieben wird. Bei dieser Ausgabe handelt es sich in der Regel um Dienststart- oder BS-Meldungen.
bg{id}-bootstrap-ca.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
bg{id}-ca.log
Nur-Text
Das primäre Protokoll für alle Aktivitäten aus dem Hintergrunddienst.
bg{id}-dwh.log
Nur-Text
Data Warehouse-spezifische Aktivitäten im Hintergrunddienst.
bg{id}-process-engine.log
Nur-Text
Ereignisse, die über den Monitor der Prozess-Engine im Hintergrunddienst aufgezeichnet werden.
bg{id}-system.log
Nur-Text
Ausgabe auf Systemebene, die direkt in die Konsole (STDOUT) für den Hintergrunddienst geschrieben wird. Bei dieser Ausgabe handelt es sich in der Regel um Dienststart- oder BS-Meldungen.
completion.log
Eigenschaften
Eine Aufzeichnung der Installations- oder Upgrade-Schritte, die für die einzelnen Komponenten abgeschlossen wurden. Ändern Sie dieses Protokoll nicht ohne die Unterstützung von CA Support.
dbtools-bootstrap-ca.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
dbtools-ca.log
Nur-Text
DBTools-Aktivitäten. DBTools ist ein Tool, das Datenbankentitäten und -daten während eines Upgrade- oder Patch-Prozesses ändert.
dbtools-dwh.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
dbtools-process-engine.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
nsa-access-{date}.log
Nur-Text
Sitzungsaktivität (http/s-Anforderungen) für den Systemverwaltungsdienst.
nsa-bootstrap-ca.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
nsa-ca.log
Nur-Text
Das primäre Protokoll für alle Aktivitäten aus dem Systemverwaltungsdienst.
nsa-dwh.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
nsa-process-engine.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
nsa-system.log
Nur-Text
Ausgabe auf Systemebene, die direkt in die Konsole (STDOUT) für den Systemverwaltungsdienst geschrieben wird. Bei dieser Ausgabe handelt es sich in der Regel um Dienststart- oder BS-Meldungen.
odf-bootstrap-bootstrap-ca.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
odf-bootstrap-ca.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
odf-bootstrap-dwh.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
odf-bootstrap-process-engine.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
upgrade-bootstrap-ca.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
upgrade-ca.log
Nur-Text
Meldungen von einzelnen
Classic PPM
-Upgrade-Skripts, die bei einem Upgrade-Prozess ausgeführt werden.
update-dwh.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
upgrade-process-engine.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
xogAdmin-bootstrap-ca.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
xogAdmin-ca.log
Nur-Text
Aktivitäten vom XOG Admin-Client. XOG Admin-Client ist ein Tool, das Daten während eines Upgrade- oder Patch-Prozesses einfügt oder ändert.
xogAdmin-dwh.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
xogAdmin-process-engine.log
Leer
Diese Datei wird automatisch generiert und ist normalerweise leer.
Bearbeiten der Protokollierungskonfiguration
Bei den
ca
-Protokolldateien handelt es sich um die primären Protokolldateien. Die meisten Informationen, die das Produkt erfasst, werden in einer dieser Dateien aufgezeichnet. Dies umfasst nicht nur Systemfehler, sondern auch Informationsmeldungen wie z. B. Debug-Nachrichten. Sie können konfigurieren, welche Protokollmeldungen in den ca-Protokolldateien angezeigt werden.
Zwei wichtige Attribute von Protokollnachrichten:
  • Kategorie
    Gibt die Stelle im Produkt, von der die Nachricht gemeldet wurde, an.
  • Ebene
    Gibt den Schweregrad der Nachricht an.
Sie können die Protokollierung so konfigurieren, dass Protokollnachrichten nach Kategorie und Ebene gefiltert werden. Im Produkt werden alle Nachrichten der Kategorie com.ca mit Ebene "Fehler" oder höher ("Schwerwiegend") gemeldet. Sie können zusätzliche Kategorien mit Informationen oder Debug-Ebenen hinzufügen, um bei Problembehandlungsvorgängen weitere Informationen zu erhalten.
Wenn mehrere
Classic PPM
-Hintergrunddienste (bg) ausgeführt werden und Debugging aktiviert ist, um ein Problem mit einem
Classic PPM
-Hintergrunddienst (bg) zu beheben, empfiehlt es sich, alle Dienste außer dem Dienst, für den das Debugging durchgeführt wird, zu beenden. Dadurch wird sichergestellt, dass alle Aufträge oder Prozesse über diesen
Classic PPM
-Hintergrunddienst (bg) laufen und somit die gewünschten Debug-Nachrichten generiert werden. Starten Sie den
Classic PPM
-Hintergrunddienst neu, damit die Änderungen in Kraft treten, und prüfen Sie danach die Protokolldatei (bg-ca.log).
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Klicken Sie auf Startseite, Server.
  3. Um die Protokollinformationen zu bearbeiten, klicken Sie auf das Eigenschaftssymbol für den Server.
  4. Klicken Sie auf die Registerkarte "Protokolle".
  5. Klicken Sie auf die Unterregisterkarte "Konfiguration bearbeiten".
  6. Füllen Sie im Bereich "Eigenschaften" die folgenden Felder aus:
    • Änderungen an der Protokollkonfiguration automatisch erkennen
      Zeigt an, ob die Änderungen der Protokollkonfiguration sofort in Kraft treten. Aktivieren Sie dieses Kontrollkästchen, damit die vorgenommenen Änderungen sofort wirksam werden. Diese Option gilt für
      Classic PPM
      -Hintergrunddienste (bg) und
      Classic PPM
      -Anwendungsdienste (app), die unter Apache Tomcat ausgeführt werden.
      Wenn Sie diese Option aktivieren, starten Sie alle betroffenen Dienste neu, um sicherzustellen, dass die Änderung übernommen wird.
    • Alternatives Protokollverzeichnis
      Gibt das alternative Protokollverzeichnis für diesen Server an. Hierbei muss es sich um einen gültigen absoluten Pfad zu einem Verzeichnis auf dem Server handeln. Zum Beispiel: "/niku/logs" (Unix) oder "E:\logs" (Windows).
    • Standard-Grenzwert zur Nachverfolgung (Sekunden)
      Gibt den grundlegenden Grenzwert an, über dem Nachverfolgungsinformationen für eine bestimmte Anforderung geschrieben werden. Dieser Wert überschreibt die Kategorieebenen der Datei "logger.xml".
  7. Füllen Sie im Bereich "Systemprotokollierung" die folgenden Felder aus:
    • Höchstanzahl von Systemprotokollen (pro Dienst)
      Gibt die Anzahl von Systemprotokolldateien an, die für die einzelnen Dienste beibehalten werden sollen. Eine Änderung dieses Werts macht einen Neustart der Dienste erforderlich. Der Standardwert ist fünf.
    • Maximale Größe der einzelnen Systemprotokolle
      Gibt die Größe der Systemprotokolldateien für die einzelnen Dienste in Megabyte an. Eine Änderung dieses Werts macht einen Neustart der Dienste erforderlich. Der Standardwert ist 5 MB.
  8. Füllen Sie im Bereich "Kettle-Protokollierung" die folgenden Felder aus:
    • Kettle-Protokollebene
      Gibt die Ebene der Protokollaktivität an, die angezeigt werden soll, wenn die Aufträge "Data Warehouse laden" und "Data Warehouse-Zugriffsrechte laden" ausgeführt werden. Die Protokolldaten werden in den Data Warehouse-Protokollen in CSA gespeichert.
      Werte
      : Nichts, Fehler, Minimal, Standard, Detailliert oder Zeilenebene.
  9. Füllen Sie im Bereich "Persistenz-Protokollierung der Prozess-Engine" die folgenden Felder aus:
    • Persistenz-Protokollebene der Prozess-Engine
      Gibt die Ebene der Protokollaktivität an, die angezeigt wird, wenn Sie den Tag <gel:log> in Ihr Prozess-GEL-Skript aufnehmen. Wählen Sie aus den folgenden Werten, um zu konfigurieren, welche Art von Nachrichten auf der Seite "Startseite, Organizer, Initiiert - Prozesse" angezeigt werden:
      • Fehler. Der Standardwert gibt an, dass nur Nachrichten mit <gel:log level=ERROR> als Meldungen auf der Benutzeroberfläche angezeigt werden. Wir empfehlen diese Einstellung, um die Größe der Tabelle "BPM_ERRORS" klein zu halten.
      • Warnen. Der Standardwert gibt an, dass Nachrichten mit <gel:log level=ERROR oder gel:log level=WARN> als Meldungen auf der Benutzeroberfläche angezeigt werden.
      • Info Der Standardwert gibt an, dass alle Nachrichten (auch ohne Protokollebene) als Meldungen auf der Benutzeroberfläche angezeigt werden.
  10. Klicken Sie im Bereich "Grenzwerte nachverfolgen" auf "Grenzwert hinzufügen", und füllen Sie die folgenden Felder aus:
    • Grenzwert (Sekunden)
      Gibt die Anzahl von Sekunden an, nach deren Ablauf die von den Aktionsmustern identifizierten Aktionen verfolgt werden. Bei einem Wert von -1 ist kein Grenzwert für die angegebenen Aktionen festgelegt. Dieser Wert wird empfohlen, um Grenzwerte für langfristige Aktionen zu deaktivieren.
    • Muster
      Gibt die Aktionen an, die verfolgt werden, wenn der Grenzwert überschritten wird. Geben Sie das Muster in einem Format mit Kommas als Trennzeichen ein. Beispiel: webRequest/npt.overview, xogRequest/XOG::project::read oder serviceRequest/*.
  11. Füllen Sie im Bereich "Kategorien" die folgenden Felder aus:
    • Name/Anderer Name
      Gibt die Kategorie für das Hinzufügen oder Ändern an. Wählen Sie eine Option in der Dropdown-Liste aus. Um eine Kategorie zu aktivieren, die nicht in dieser Liste aufgeführt ist, geben Sie sie in das Textfeld "Anderer Name" ein.
    • Appender
      Leitet die Protokollausgabe an ein anderes Ziel. Um eine Kategorie an eine separate Datei zu leiten, fügen Sie einen neuen STDOUT-Appender mit einem eindeutigen Dateinamen hinzu, und verbinden Sie die Kategorie mit dem neuen Appender.
    • Priorität
      Definiert die Debug-Ebene. Je höher die Ebene, umso höher die Priorität.
      Werte:
      • Schwerwiegend. Zeigt an, dass ein kritischer Dienst nicht ausgeführt wird.
      • Fehler. Zeigt ein Problem an, das Systemfunktionen beeinträchtigen kann.
      • Warnen. Zeigt an, dass in
        Classic PPM
        ein Problem aufgetreten ist, die Anwendung aber weiterhin ausgeführt wird.
      • Info Zeigt den Systemstatus (z. B. Dienststart) an und steht nicht immer für ein Problem.
      • Debuggen. Zeigt ausführliche Informationen an, die Sie oder den technischen Support von CA dabei unterstützen, ein Problem zu lösen.
      • Nachverfolgen. Zeigt technische Informationen auf unterster Ebene an. Diese Ebene führt zur Erstellung großer Datenmengen. Verwenden Sie diesen Wert nur, wenn Sie vom technischen Support von CA dazu aufgefordert werden.
      • Alle. Zeigt alle Meldungen an.
    • Zusatz
      Zeigt an, ob neue Meldungen an die Protokolle angehängt sind. Aktivieren Sie dieses Kontrollkästchen, um Nachrichten anzuhängen. Wenn dieses Kontrollkästchen deaktiviert ist, können Protokolle mit neuen Informationen überschrieben werden.
  12. Speichern Sie die Änderungen.
  13. Starten Sie die betroffenen Dienste neu.
Die Protokollierung verringert möglicherweise die Systemleistung, besonders bei höheren Prioritäten wie "Debuggen" und "Ablaufverfolgung". Aktivieren Sie die zusätzliche Protokollierung nur, wenn dies erforderlich ist oder wenn Sie vom technischen Support von CA dazu aufgefordert werden. Deaktivieren Sie die zusätzliche Protokollierung, sobald sie nicht mehr benötigt wird.
Benutzerspezifische Protokollierung
Manche Protokollkategorien können speziell für bestimmte Benutzer aktiviert werden. Um die Protokollierung für einen bestimmten Benutzer zu aktivieren, hängen Sie den Benutzernamen am Ende der standardmäßigen Protokollierungskategorie an. Zum Beispiel aktiviert
trace.server.user.jsmith
serverseitige Leistungsprotokollierung für den Benutzer jsmith. Das Schlüsselwort "user" gibt an, dass es sich beim letzten Segment der Kategorie um den Benutzernamen handelt. Der Benutzername wird beim Protokollieren von Ereignissen der Kategorie als Filter verwendet. In diesem Fall ist dies die Kategorie "trace.server". Änderungen an den Einstellungen der SQL-Protokollierung für einen bestimmten Benutzer werden erst wirksam, wenn sich der Benutzer anmeldet. Aus diesem Grund muss sich der Benutzer nach einer benutzerspezifischen Änderung der Protokollierungskonfiguration immer erneut anmelden.
Aktions-Tracing
Führen Sie Aktions-Tracing (früher als SQL Trace oder SQL-Ablaufverfolgung bezeichnet) nur auf Anforderung und unter Anleitung des technischen Support von
Classic PPM
durch. Führen Sie diese Aktivität nur für eine kurze Zeitdauer durch, um Fehler für bestimmte Aktionen zu beheben. Die Aktions-Ablaufverfolgung muss dann deaktiviert werden.
Video: SQL Trace-Aktivierung
Das folgende Video wird von CA Technologies bereitgestellt.

Um dieses Video im Vollbildmodus wiederzugeben, klicken Sie auf das YouTube-Logo rechts neben den Einstellungen im unteren Video-Bereich.
Sichern einer
Classic PPM
-Installation
Wenn Sie umfassende Aktualisierungen für ein Produktionssystem planen, sichern Sie das aktuelle System, sodass Sie es ggf. wiederherstellen können. Um die Sicherungskopie der Datenbank zu speichern, verwenden Sie das Sicherungsverzeichnis.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an, und stellen Sie sicher, dass alle Dienste außer dem Datenbankdienst angehalten wurden. Wenn der Datenbankdienst nicht installiert ist, sind diese Informationen für Sie irrelevant.
  2. Öffnen Sie eine Befehlszeile auf dem CSA-Anwendungsserver, und geben Sie folgenden Befehl ein:
    admin backup
  3. Drücken Sie die Eingabetaste, um die Standardwerte zu übernehmen.
    Der Befehl "backup" kopiert das
    Classic PPM
    -Installationsverzeichnis in ein Sicherungsverzeichnis.
Sichern einer Oracle-Datenbank
Gehen Sie wie folgt vor:
  1. Verwenden Sie über die Befehlszeile des Datenbankservers das Dienstprogramm Oracle Database Export,
    expdp
    .
    Detaillierte Informationen zur Verwendung dieses Dienstprogramms finden Sie in der Oracle-Dokumentation. Das folgende Beispiel ist ein Exportbefehl:
    expdp clarity/password FULL=y DIRECTORY=data_pump_dir DUMPFILE=clarity.dmp LOGFILE=myclarityexp.log SCHEMAS=clarity
  2. Kopieren Sie die Dateien ".dmp" und "init<SID>.ora" in das Sicherungsverzeichnis, das durch den Befehl "backup" erstellt wurde.
Sichern einer Microsoft SQL Server-Datenbank
Verwenden Sie zum Sichern einer Microsoft SQL-Datenbank SQL Server Enterprise Manager. Ausführliche Informationen finden Sie in der Microsoft-Dokumentation.
Wiederherstellen einer
Classic PPM
-Installation
Der Vorgang zum Wiederherstellen einer Installation verwendet die Sicherungen des Dateisystems und der Datenbank, die vor Beginn des Upgrade-Vorgangs erstellt wurden.
Best Practice:
Stellen Sie eine
Classic PPM
-Installation nur dann wieder her, wenn alle anderen Optionen erfolglos geblieben sind.
Gehen Sie wie folgt vor:
  1. Beenden Sie alle Dienste über die Befehlszeile.
    service stop all
  2. Stellen Sie die Datenbank mit Ihren standardmäßigen Datenbankverwaltungs-Tools und der Sicherung, die vor Beginn des Upgrade-Vorgangs erstellt wurde, wieder her.
  3. Stellen Sie
    Classic PPM
    mithilfe des Wiederherstellungsskripts aus dem Sicherungsverzeichnis wieder her:
    (
    Windows
    )
    restore.bat
    (
    Unix
    )
    restore.sh
    Weitere Informationen finden Sie unter
    Sichern einer
    Classic PPM
    -Installation
    .
  4. Starten Sie anschließend alle Dienste neu:
    service start all
  5. (Optional) Installieren Sie ältere Berichtsdienste erneut.
    Weitere Informationen finden Sie unter
    Installation und Upgrade
    für die Version, für die Sie Berichte installiert haben.
Kompilieren und Analysieren vorhandener Oracle-Datenbankobjekte
Kompilieren und analysieren Sie die Datenbank in folgenden Situationen:
  • Wenn Sie die Datenbank für Upgrade-Tests exportieren und auf einen anderen Server importieren
  • Wenn Sie die Datenbank auf Ihrem Produktionsserver neu organisieren
Kompilation und Analyse stellen sicher, dass alle Datenbankobjekte gültig sind. Wenn die Datenbankobjekte vor dem Upgrade des
Classic PPM
-Schemas nicht kompiliert werden, können Upgrade-Fehler auftreten.
Gehen Sie wie folgt vor:
Öffnen Sie eine Befehlszeile auf dem CSA-Anwendungsserver, und geben Sie die folgenden Befehle ein:
admin db compile admin db analyze
Die Datenbankobjekte werden kompiliert und analysiert.
Festlegen der Größe des Dateiverzeichnisses
In CSA können Sie eine Größenbeschränkung für den Dateispeicher auf Verzeichnisebene angeben. Wenn eine Größenbeschränkung angegeben ist, wird automatisch ein neues gleichgeordnetes Verzeichnis erstellt, in dem Dateien gespeichert werden, wenn die Größenbeschränkung erreicht ist. Die Größenbeschränkung gilt auch für Dokumente, die Sie mithilfe von XML Open Gateway (XOG) in
Classic PPM
importieren.
Eine Größenbeschränkung für das Verzeichnis hat keine Auswirkungen auf die Größe bereits vorhandener Ordner.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Öffnen Sie die Startseite, und klicken Sie auf "Server".
  3. Klicken Sie auf einen Servernamen.
  4. Klicken Sie auf die Unterregisterkarte "Dokumente und Suche".
  5. Geben Sie im Bereich "Dokumentmanager - Optionen" im Feld "Größenbeschränkung für Dateispeicherverzeichnis" für ein Verzeichnis eine Größenbeschränkung für Dateispeicher an.
Festlegen von GEL-Tag-Einschränkungen
Verwenden Sie die folgenden Befehle, um GEL-Tag-Einschränkungen zu steuern:
admin general restrict-gel-tags
Setzt den Wert der Eigenschaft "gelTagRestriction" auf
on
.
admin general allow-gel-tags
Setzt den Wert der Eigenschaft "gelTagRestriction" auf
off
.
Durch den Verweis auf die Eigenschaft "gelTagRestriction" wird ermittelt, ob die GEL-Tags eingeschränkt sind. Die Eigenschaft befindet sich im Systemelement. Das Element ist optional.
Verwenden Sie die Werte
on
oder
off
, um GEL-Tag-Einschränkungen für die Umgebung festzulegen. Alle Werte außer
off
aktivieren die GEL-Tag-Einschränkung. Standardmäßig sind GEL-Tag-Einschränkungen deaktiviert.
Um die GEL-Tag-Einschränkungen zu ändern, müssen Sie die Dienste app und bg neu starten.
Beispiele
Datei "properties.xml" ohne GEL-Tag-Einschränkung:
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="true"/>
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="true" gelTagRestriction="off"/>
Datei "properties.xml" mit GEL-Tag-Einschränkung:
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="false" gelTagRestriction="on"/>