Aufgabe: Eine Datenbank 10g R2 (Version 10.2.0.5) soll auf die Version 11g R2 mit aktuellem CPU Patch upgegradet werden.

Ablauf:

• Betriebssystem Voraussetzungen überprüfen und bei Bedarf optimieren/nachinstallieren
• Software über Meta-Link auf dem Server bereitstellen
• Datenbank Software in eine neues Home installieren
• Datenbank Umgebung anpassen
• Datenbank Software patchen
• Aktuelle DB sichern und Sicherungs-Skript deaktivieren
• Datenbank „aufräumen“ / Fehler wie invalid Objects aus der Anwendung fixen bzw. dokumentieren
• PreUprade Utility durchführen and Ergebnisse ausarbeiten/erfüllen
• SPfile der DB in Text Format exportieren
• AutoTasks der Datenbank stoppen
• Applikation stoppen und letze Archive der DB sichern
• Datenbank prüfen und Dateidateien auf Block Fehler checken
• Logfiles und alte Sicherungen bereinigen / Plattenplatz optimieren
• Listener im alten Home stoppen und im neuen Home aktivieren / Autostart einrichten
• Datenbank auf neues Oracle Home umstellen
• Datenbank upgraden
• Datenbank prüfen und auf SPFile umstellen
• Applikation starten
• Backup wieder aktivieren / Umgebung aufräumen
• AutoTasks der Datenbank wieder starten
• 11g Securtiy Features beachten
• Übersicht über den Zeitlichen Ablauf

Die Installation der Oracle Datenbank Software erfolgt in ein neues Oracle Home parallel zu dem bereits existierenden Oracle Home und unter dem gleichen Solaris User.

Um den Upgrade zu beschleunigen, wird empfohlen die DBConsole/Grid Control zuvor auf der DB zu deinstallieren und nach dem Upgarde neu aufzusetzen.

Im Beispiel ist die ORACLE_SID = GPI !

Quellen:

• Oracle® Database Upgrade Guide 11g Release 2 (11.2)
• Oracle® Database Installation Guide 11g Release 2 (11.2) for Oracle Solaris

User: root

Bzgl. der Voraussetzungen siehe auch die Anleitung bei einer neuen Installation: Installationsanleitung 11g R2

# Version
uname -a
SunOS db5 5.10 Generic_142900-04 sun4u sparc SUNW,Sun-Fire-xxx
# Version über /etc/release
cat /etc/release
            Solaris 10 5/08 s10s_u5wos_10 SPARC
           Copyright 2008 Sun Microsystems, Inc. 
           ..
# Version 
showrev
...
Kernel version: SunOS 5.10 Generic_142900-04
...
#Bit Version prüfen
/bin/isainfo -kv                                                                                                     
 
64-bit sparcv9 kernel modules
 
# Version über Metalink prüfen
pkginfo -l SUNWsolnm | grep VERSION
VERSION:  10,REV=2008.03.24.13.19

Um die Ausgabe von „pkginfo -l SUNWsolnm | grep VERSION“ zu interpretieren siehe die Liste: How to Determine the Release and Default Kernel Version in the Solaris Operating System [ID 1002239.1]

Was sagt uns nun diese Ausgaben:

• „Solaris 10 5/08 s10s_ u5 wos_10 SPARC“ ⇒ Hier ist das update 5 installiert
• „VERSION: 10,REV=2008.03.24.13.19“ ⇒ „Solaris 10 5/08 (Update 5)“ installiert
• „SunOS 5.10 Generic_142900-04“ ⇒ Kernel Bug Fixes post Solaris 10 10/09 (Update 8)

Der OUI (der Installer) erkennt aber in dieser Installation nun nur den Kernel 5.10-2008.5.

ABER ⇒ Oracle 11g benötigt 5.10-2008.10 bzw. das Update 6 oder höher D.h. das Update wurde nicht „komplett“ eingespielt. Ein Workaround: Neuinstallation des SUNWsolnm Packages mit Hilfe des zuletzt gewählten Update Paket und testen ob nun die Version richtig angezeigt wird.

Oracle warnt allerdings, dass wenn /etc/relase nicht aktualisiert wurde, wurde auch das Update nicht „richtig“ bzw. vollständig durchgeführt/eingespielt, es wurden nur für die bestehenden Pakete ein Update durchgeführt, ein vollständiges Update kann auch neue Pakete enthalten! Siehe auch das FAQ unter ⇒ "FAQ - 11gR2 requires Solaris 10 update 6 or greater [ID 971464.1]"

Bzgl. der Solaris Versionen siehe auch:
⇒ Solaris 10 Kernel PatchID Sequence

#Package Info:
pkginfo -i SUNWarc SUNWbtool SUNWhea SUNWlibC SUNWlibms SUNWsprot SUNWtoo SUNWi1of SUNWi1cs SUNWi15cs SUNWxwfnt

Den Patch Stand von Solaris überprüfen (für eine Standard DB reichen die folgenden Patch, je nach Anwendung die Original Anleitung sorgfältig prüfen!): \

Patches for Oracle Solaris 10:

• 120753-06: SunOS 5.10: Microtasking libraries (libmtsk) patch
• 139574-03: SunOS 5.10
• 141414-02
• 141444-09
• 119963-14

/usr/sbin/patchadd -p | grep 120753
/usr/sbin/patchadd -p | grep 139574
/usr/sbin/patchadd -p | grep 141414
/usr/sbin/patchadd -p | grep 141444
 
# alternativ
showrev -a | grep 119963

Überprüfen das die Patche wie besonders der 120753 mindestens in der angegebenen Version (06 oder höher) vorliegen!

Ziel ist es die neuen DB Software „neben“ der bestehenden Software d.h. in der gleichen Struktur zu installieren.

cd /opt/oracle/product/
df -h .
 
#Hier sollten mindestens noch 5 GB Plattenplatz frei sein.
 
cd /tmp
df -h .
 
Hier sollten mindestens noch 2 GB Plattenplatz frei sein.

In der Datei /etc/system die Kernel Parameter überpüfen, hier ist dann allerdings später ein Reboot notwendig!

Für die TCP Settings:

Angepasst werden mussten:

• Kernel parameter for „tcp_smallest_anon_port“ = 9000
• Kernel parameter for „tcp_largest_anon_port“ = 65500
• Kernel parameter for „udp_smallest_anon_port“ = 9000
• Kernel parameter for „udp_largest_anon_port“ = 65500

Dazu:

# als root
 
vi /etc/init.d/ndd
 
#!/bin/sh
# TCP Setting for the Oracle Cluster
ndd -set /dev/tcp tcp_smallest_anon_port 9000
ndd -set /dev/tcp tcp_largest_anon_port 65500
ndd -set /dev/udp udp_smallest_anon_port 9000
ndd -set /dev/udp udp_largest_anon_port 65500 
 
chmod 744 /etc/init.d/ndd
chown root:sys /etc/init.d/ndd
ln /etc/init.d/ndd /etc/rc2.d/S70ndd

Angepasst werden mussten:

Siehe auch Metalink node „Kernel setup for Solaris 10 using project files [ID 429191.1]“

Hardlimits:

• Hard limits for „maximum open file descriptors“ = 65536

Über den „project“ Mechanismus setzen ( in diesem Fall auf die group.dba oder evlt. auch user.oracle ):

# user root
projmod -s -K "process.max-file-descriptor=(priv,65536,deny)" group.dba

• Hard limits for „maximum user processes“ = 16384

Über „/etc/system“ setzen:

# als root
vi /etc/system
 
..
set maxuprc=16384
set rlim_fd_max=65536
set max_nprocs=30000
 
..

Softlimit: * Soft limits for „maximum open file descriptors“ = 1024 oder höher

Kann in der .bash_profile angepasst werden:

vi ~/.bash_profile
 
# .bash_profile
umask 0022
ulimit -n 1024

In einer cluster Umgebung Zeitdienst pürfen:

# als root diese beiden Parameter in die ntp.conf einfügen!
vi /etc/inet/ntp.conf
..
slewalways yes
disable pll
..

User: oracle

Für die Installation der eigentlichen Datenbank Software die beiden ersten Zip Files (1,4GB, 1.1GB) vom Patch 10404530 „11.2.0.3.0 PATCH SET FOR ORACLE DATABASE SERVER“ auf den Server in das Verzeichnis /export/oracle/home/install laden.

Md5 Checksumme überprüfen:

digest -v -a md5 p10404530_112030_SOLARIS64_1of7.zip                                                             
md5 (p10404530_112030_SOLARIS64_1of7.zip) = 9f8bf7879870520a87ec95a1746fe693
digest -v -a md5 p10404530_112030_SOLARIS64_2of7.zip                                                                 
md5 (p10404530_112030_SOLARIS64_2of7.zip) = 18c91b60cad09bb2f33a2da64dd62a57

Mit dem Screen bei Metalink vergleichen:

Sind weiter Patche für die Datenbank notwendig, diese ebenfalls von Metalink laden. Wichtig ist immer der Patch des Patch Installers (Path Nummer 6880880). Dieser wird immer benötigt! Typische weitere Patche:

• Patch 6880880: OPatch patch of version 11.2.0.3.2 for Oracle software releases 11.2.0.x (NOVEMBER 2012)
• Patch 14038787: CPUJUL2012 DATABASE 11.2.0.3 (3,8M)

Den Datenbank Patch mit „unzip“ extrahieren.

User: oracle

Für den Start des Oracle Installers benötigen sie eine graphische Oberfläche bzw. ein passendes X forwarding. Ich empfehle für die Wartung NoMachine NX (siehe http://www.nomachine.com/ ).

Testen Sie diese zuvor mit „xclock &“.

Wechsel Sie in das /export/home/oracle/install/database Verzeichnis.

Prüfen ob die Befehle make, ar, ld, und nm im Pfad stehen. Falls nicht Pfad erweitern:

 export PATH=$PATH:/usr/ccs/bin

Starten Sie dort ./runInstaller.sh und die gewünschte Datenbank Version wird installieren. Wählen Sie die Option „Nur die DB Software installieren“!

Prüfen der Ausgaben des „Perform Prerequisite Checks“ Screen und fixen der dort angezeigten Fehler. Mit den „Ignore“ Button können Sie die Fehler auch überspringen.

Auf den Plattenplatz achten, evtl. nach der Installation das Database Installations-Verzeichnis löschen! (gibt immer hin 2,4GB wieder frei!)

User: oracle

Je nachdem wie die Datenbankumgebung eingerichtet ist, (zum Beispiel so: Arbeitsumgebung setzen und einrichten unter Windows und Linux das neuen Oracle Home mitaufnehmen.

User: oracle

Vor dem Patch der DB Software muss der Patch Installer OPatch aktualisiert werden.

Test der aktuellen Version:

cd $ORACLE_HOME/OPatch
./opatch version                                                                                                  
 
  ./opatch: whereis: not found
 
  Invoking OPatch 11.2.0.1.7
 
  OPatch Version: 11.2.0.1.7

Der Fehler whereis kann ignoriert werden.

Die Aktualisierung besteht darin, das komplette Verzeichnis OPatch auszutauschen, den OPatch Patch auspacken und dann in das OPatch Verzeichnis unter $ORACLE_HOME ersetzen.

# altes OPatch sichern
cd $ORACLE_HOME/OPatch
mv OPatch OPatch_OLD
 
# neues OPatch auspacken
cd /export/home/oracle/install
unzip p6880880_112000_SOLARIS64.zip  -d  $ORACLE_HOME
 
# testen
cd $ORACLE_HOME/OPatch
./opatch version
 
OPatch Version: 11.2.0.3.2

Prüfen ob die Befehle make, ar, ld, und nm im Pfad stehen. Falls nicht Pfad erweiter:

 export PATH=$PATH:/usr/ccs/bin

# Neues Oracle Home setzen
export $ORACLE_HOME=/opt/oracle/product/11.2.0.3/dbhome_1
 
# Patch auspacken
cd /export/home/oracle/install
unzip p14038787_112030_SOLARIS64.zip
cd 14038787
 
# Patch anwenden
$ORACLE_HOME/OPatch/opatch napply -skip_subset -skip_duplicate

Sind noch weitere Patche notwendig, diese nach diesem Muster einspielen.

User: oracle

Aktuelle DB unter 10g komplett sichern.

# Editor setzen
export EDITOR=vi
# crontab zum bearbeiten öffenen und mit # auskommentieren
crontab -e

User: oracle

In der bestehenden Datenbank auf Fehler prüfen wie: siehe auch Ungültige Objekte in der DB "reparieren"

sqlplus / as sysdba
 
SQL> select owner
      ,object_type
      ,count(*)  as anzahl
from all_objects 
where status!='VALID' 
group by rollup (owner,object_type)
/
 
# falls viele Fehler auftauchen 
# ungültige Objekte in der Datenbank neu übersetzen
 
sql>@?/rdbms/admin/utlrp.sql

Papierkorb der DB Löschen

sqlplus / as sysdba
 
SQL>PURGE DBA_RECYCLEBIN;

Überprüfen ob die Audit log Tabelle aud$ sehr viele Einträge enthält:

SELECT COUNT(*) FROM aud$;
 
-- falls ja und die Daten NICHT benötigt werden, löschen
TRUNCATE TABLE aud$;

User: oracle

Mit dem Script /opt/oracle/product/11.2.0.3/dbhome_1/rdbms/admin/utlu112i.sql (Script aus den neuen Oracle Home!) wird in der zu aktualisierenden Datenbank geprüft welche Schritte VOR dem Upgrade auf der DB durchgeführt werden müssen.

Es wird empfohlen die aktuellest Version des Pre-Upgrade Scripts über „How to Download and Run Oracle's Database Pre-Upgrade Utility (Doc ID 884522.1)„ vom Oracle Support Portal zu verwenden.

# DB umgebung auf die "Alte" Datenbank setzen
 
sqlplus / as sysdba
 
sql>spool upgrade_info.log
sql>@/opt/oracle/product/11.2.0.3/dbhome_1/rdbms/admin/utlu112i.sql
SQL>spool off

Für den Upgrade der Zeitzonen Dateien auf V14 siehe auch Applying the DSTv14 update for the Oracle Database [ID 1109924.1]

von dieser Seite für den Test die Datei „utltzuv14.sql“ laden.

Test:

sqlplus / AS sysdba
 
sql>SELECT version FROM v$timezone_file;
4
sql>@utltzuv14.sql
 
sql>SELECT * FROM sys.sys_tzuv2_temptab

Falls keine Zeilen bzgl. der Nutzdaten der Applikation ausgegeben werden kann ein Upgrade erfolgen. Falls Daten aktualisiert werden müssten, sollte der Patch 9742718 auf der alten DB eingespielt werden und mit DBMS_DST Package die Daten angepasst werden.

Ergebnisse auswerten und Vorschläge durchführen.

Siehe auch About the Output of the Pre-Upgrade Information Tool

Falls sehr viele Einträge im Audit log sind Metalink Node Oracle Support Document 1329590.1 (How to Pre-Process SYS.AUD$ Records Pre-Upgrade From 10.1 or later to 11gR1 or later.) beachten.

siehe auch http://docs.oracle.com/cd/E11882_01/server.112/e23633/statistics.htm für ein komplettes Script.

sql>exec  DBMS_STATS.gather_dictionary_stats;
sql>exec  DBMS_STATS.gather_fixed_objects_stats;
 
sql>exec DBMS_STATS.gather_schema_stats ('SYS', options => 'GATHER', estimate_percent => DBMS_STATS.auto_sample_size, cascade => TRUE);
 
sql>exec DBMS_STATS.gather_schema_stats ('SYSMAN', options => 'GATHER', estimate_percent => DBMS_STATS.auto_sample_size, cascade => TRUE);
 
# Optional!
# für alles IN der DB was noch nicht ermittelt wurde! Kann dauern!
sql>exec DBMS_STATS.GATHER_DATABASE_STATS (degree=>4,options=>'GATHER AUTO' );

SPfile in eine text basierende init.ora exportieren um später eine Vorlage für das Anpassen von Parameter für das erste Starten der DB beim Upgrade zuhaben.

sql>CREATE pfile='/export/home/oracle/init.ora' FROM spfile;

Meist testen man tagsüber und vergisst das nachts so einiges in der Datenbank loss sein kann.

Lieder können die Autotasks der DB erst ab 11g mit DBMS_AUTO_TASK_ADMIN.DISABLE deaktiviert werden.

Sheduler daher komplett ausschalten:

sqlplus / AS sysdba
 
SET serveroutput ON
DECLARE
 v_info varchar2(100);
BEGIN
  dbms_output.put_line('-- Info -> Set SCHEDULER_DISABLED to disabled = TRUE ');
  dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED','TRUE'); 
 
  dbms_scheduler.get_scheduler_attribute('SCHEDULER_DISABLED', v_info);
  dbms_output.put_line('-- Info -> SCHEDULER_DISABLED :: ' || nvl(v_info,'NOT SET'));
 
END;
/

Mit RMAN nochmals alle Archive und das Controlfile seit dem letzen Backup sichern um den letzen Stand vor dem Upgrade zu haben.

# alte Umgebung!
 
rman
 
rman>connect target /
rman>backup archivelog all not backed up 1 times;
rman>backup spfile;
rman>backup current controlfile;

User : oracle

SELECT * FROM v$recover_file;

SELECT * FROM v$backup WHERE STATUS != 'NOT ACTIVE';

SELECT * FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) = 8;

SQL> SELECT * FROM dba_2pc_pending;
 
# falls IN USE
 
SQL> SELECT local_tran_id FROM dba_2pc_pending;
SQL> EXECUTE dbms_transaction.purge_lost_db_entry('');
SQL> COMMIT;

Mit dem Tool DBVERIFY: Offline Database Verification Utility werden die Datendateien der Datenbank auf Blockfehler überprüft.

Wie: „dbv BLOCKSIZE=8192 file=/opt/oracle/oradata/gpi/system01.dbf FEEDBACK=1000“

Die Befehle über die Liste der Datendateien aus dem DD erzeugen:

sqlplus / as sysdba
 
sql>set pagesize 100
sql>column dbvcommand format a100
 
sql>select 'dbv file='||name||' BLOCKSIZE='||block_size as dbvcommand from v$datafile;
 
DBVCOMMAND
--------------------------------------------------------------------------------
dbv file=/opt/oracle/oradata/GPI/system01.dbf BLOCKSIZE=8192
 
...
 
 
sql>exit

Erzeugte Befehle ausführen und auf Fehler achten.

Datenbank stoppen

sql>shutdown IMMEDIATE

DBV Befehle ausführen

dbv file=/opt/oracle/oradata/TNGIP5/system01.dbf BLOCKSIZE=8192

Die audit Dateien und die Alert.log der alten Datenbank mit Tar einpacken und zippen, originale löschen. Struktur NICHT löschen!

cd /opt/oracle
tar cfv admin.tar ./admin
gzip admin.tar

Alle alten Traces in der Admin 10g Struktur löschen.

cd ./admin
 
du -h .
 
find . -type f -name "*.trc" -exec rm {} \;
find . -type f -name "*.aud" -exec rm {} \;
find . -type f -name "*.log" -exec rm {} \;
 
du -h .

Listener log ebenfalls zippen und original löschen.

# Altes Home einstellen
# Listener Status abfragen
lsnrctl status
# Listner.ora Datei merken!
# Log location merken!
 
# Listner stoppen
lsnrctl stop
 
# Listener log bei Bedarf zippen und löschen

Alte Listener Konfiguration in das neue Oracle Home kopieren ( oder falls gesetzt in des Verzeichnis auf das TNS_ADMIN zeigt!)

cp /opt/oracle/product/10.2.0/db_1/network/admin/listener.ora /opt/oracle/product/11.2.0.3/dbhome_1/network/admin

Listener.ora öffnen und evtl. Oracle Home Einträge anpassen

ADR Home angeben

..
ADR_BASE_LISTENER = /opt/oracle
..

Neues Oracle Home in der Umgebung setzen und dort den Listener starten

# Oracle Home einstellen
lsnrctl start

User : oracle

Password Datei vom alten Oracle Home in das neue Home kopieren

cp /opt/oracle/product/10.2.0/db_1/dbs/orapwGPI /opt/oracle/product/11.2.0.3/dbhome_1/dbs 

Erzeugte ini.ora Parameter Datei aus Schritt zuvor auf die gewünschten Parameter für 11g optimieren Datei in das 11g Home als opt/oracle/product/11.2.0.3/dbhome_1/dbs/initGPI.ora kopieren.

Minum: obsolete Paramter background_dump_dest und user_dump_dest entfernen und Parameter diagnostic_dest dafür aufnehmen, diagnostic_dest=/opt/oracle ( damit wird das ADR Home definiert um das 11g Tool adrci zu nützen).

cp initTNGIP5.ora /opt/oracle/product/11.2.0.3/dbhome_1/dbs 

Nach den ora_ Prozessen im Hauptspeicher suchen

ps -Af | grep ora_

# Neues Oracle Home setzen
 
sqlplus / AS sysdba
 
SQL> STARTUP UPGRADE
SQL> exit

2. Session als Oracle User starten, Parameter ADR_BASE auf das DIAG Home setzen, mit adrci alert.log überwachen

export ADR_BASE=/opt/oracle
 
adrci
 
adrci> show homes
ADR Homes:
diag/rdbms/GPI/GPI
 
adrci> set home diag/rdbms/GPI/GPI
 
adrci> show alert  -tail -f

in das Verzeichnis $ORACLE_HOME/rdbms/admin wechseln

# auf die richtige Oracle Umgebung achten
sqlplus / AS sysdba
 
SQL> SPOOL /export/home/oracle/upgrade.log
 
SQL> @catupgrd.sql

Diese kann zwischen 45 bis 90 Minuten dauern!

Datenbank neu starten und Post Upgrade Utility starten

# auf gültiges Oracle Home prüfen!
sqlplus / AS sysdba
 
sql>startup
 
sql>@utlu112s.sql
 
exit
sqlplus / AS sysdba
 
# weiter Upgrades durchführen
SQL>@catuppst.sql
 
#Fixed Object Statistiken erneuern:
SQL>EXEC DBMS_STATS.gather_fixed_objects_stats;
 
# ungültiges neu übersetzen
SQL>@utlrp.sql
 
# auf ungültige Objekte testen
 
SQL> SELECT COUNT(*) FROM dba_invalid_objects;
SQL> SELECT DISTINCT object_name FROM dba_invalid_objects;
 
#Prüfen ob diese auch zuvor schon ungültig waren
SQL>@?/rdbms/admin/utluiobj.sql

Noch ist die Datenbank mit der init.ora aus vorherigen Schritt gestartet. Spfile erzeugen:

CREATE spfile FROM pfile;

prüfen:

„ls /opt/oracle/product/11.2.0.3/dbhome_1/dbs/SPFILEGPI.ora“ muss vorhanden sein.

Datei /etc/oratab öffnen und Oracle Home anpassen

Pfade im Start Script der Datenbank anpassen, oft in /etc/init.d/oracle oder ähnlich

System neu starten und testen

tnsname.ora und sqlnet.ora aus alten Home nach $ORACLE_HOME/network/admin kopieren

Backup Scripte auf richtiges Oracle Home prüfen und in der Crontab wieder aktivieren.

Nach der Installation können die Installatonsdateien auf dem Server gelöscht werden.

Nagios Überwachung anpassen.

Sheduler für alle Taks wie das Erstellen der Statistik in den AutoTaks wieder einschalten:

sqlplus / AS sysdba
 
SET serveroutput ON
DECLARE
 v_info varchar2(100);
BEGIN
  dbms_output.put_line('-- Info -> Set SCHEDULER_DISABLED to enabled = FALSE ');
  dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED','FALSE'); 
  dbms_scheduler.get_scheduler_attribute('SCHEDULER_DISABLED', v_info);
  dbms_output.put_line('-- Info -> SCHEDULER_DISABLED :: ' || nvl(v_info,'NOT SET => FALSE = ENABLED'));
END;
/

Per Default ist die Password Lifetime der 11g auf 180 Tage gesetzt, Einstellungen auf der DB überprüfen und entsprechende den Sicherheitsrichtlinien nach Firmenstandard einstellen.

Überprüfen mit:

#profile Settings
SELECT profile ,LIMIT 
 FROM dba_profiles 
WHERE resource_name ='PASSWORD_LIFE_TIME' ORDER BY profile
/
 
# Einstellungen
COLUMN username format a22
COLUMN account_status format a18
COLUMN profile format a10
 
SELECT username, profile, account_status,expiry_date 
 FROM dba_users ORDER BY 1
/

Passwörter sind Case Sensitiv, falls das nicht gewünscht ist kann diese mit dem init.ora Parameter „sec_case_sensitive_logon=FALSE“ deaktiviert werden.

Davon Downtime für die Applikation 120 Minuten