Implementierung einer hochverfügbaren HANA-Datenlösung
Programmabbrüche durch Speicherknappheit
Benutzerkontextdaten werden von Dialog-Workprozessen in folgender Reihenfolge abgelegt: Beim Start einer Transaktion wird der Benutzerkontext bis zu einer Größe von ztta/roll_first im lokalen Roll-Bereich des Workprozesses gespeichert. ztta/roll_first soll auf 1 (Byte) gesetzt werden. Dies bedeutet, dass zunächst überhaupt kein SAP Roll Memory belegt werden soll. Aus technischen Gründen werden allerdings immer administrative Daten in der Größenordnung von bis zu 100 kB im lokalen Roll-Bereich des Workprozesses abgelegt, auch wenn ztta/roll_first = 1 ist. Wächst die Größe des Benutzerkontextes über den Wert ztta/roll_first hinaus, werden die Daten im SAP Extended Memory abgelegt. Ist der SAP Extended Memory erschöpft oder erreicht der Benutzerkontext die Quote von ztta/roll_extension*, wird der verbleibende Rest des lokalen Roll-Bereichs bis zu einer Größe von ztta/roll_area genutzt. Wächst der Kontext weiter an und übersteigt der Speicherbedarf auch diesen Wert, allokiert der Workprozess SAP Heap Memory nach Bedarf. Die Verwendung von SAP Heap Memory hat den Nachteil, dass dieser Speicher lokal ist und auch nicht mehr – wie beim SAP Roll Memory – in einen globalen Speicherbereich kopiert (gerollt) werden kann. Wenn ein Prozess SAP Heap Memory allokiert, kann der Kontext nicht mehr zu einem anderen Workprozess übertragen werden. Der Workprozess bleibt einem Benutzer exklusiv zugeordnet. Diesen Zustand bezeichnet man als PRIV-Modus (Private Mode). In der Workprozess-Übersicht wird dieser Zustand in den Spalten Status und Grund durch die Werte hält bzw. PRIV dokumentiert.
Bei der Interpretation der Ergebnisse sollten Sie die folgenden Faktoren berücksichtigen, die Einfluss auf das Sizing haben: Finden Sie unter den größten Tabellen im System solche, deren Inhalte vor der Migration auf SAP HANA archiviert oder gelöscht werden können? In diesem Fall kann sich der Hauptspeicherbedarf reduzieren. Wie groß ist Ihr Datenwachstum? Bestimmen Sie die jährliche Wachstumsrate, und legen Sie fest, auf wie viele Jahre Sie Ihre SAP-HANAInstallation planen wollen.
Vorbereitung der Migration auf SAP HANA
Bei allen Datenbanksystemen kann man durch Parameter die Strategie festlegen, wie oft Check- bzw. Savepoints geschrieben werden sollen. Welche Parameter das Checkpointing für Ihr spezielles Datenbanksystem festlegt, entnehmen Sie der SAP-Onlinehilfe zum Datenbankmonitor. Die von SAP ausgelieferten Parametereinstellungen sollten nur auf Anweisung von SAP verändert werden.
Die SAP-Basis ist das Fundament eines jeden SAP-Systems. Viele nützliche Informationen dazu finden Sie auf dieser Seite: www.sap-corner.de.
Administratoren müssen häufig einen Teil oder die gesamte Datenbank replizieren, zB um ein System-Backup zu erstellen oder ein Upgrade zu testen, bevor es in die Produktion übernommen wird. In der Vergangenheit war dies bei den meisten Datenbanken überraschend schwierig zu bewerkstelligen. Mit HANA funktioniert die Replikation sofort und bietet umfangreichere Funktionen und eine bessere Kontrolle als frühere Datenbanken.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Beachten Sie, daß Sie die Support Packages vor der weiteren Verarbeitung entpacken müssen.
Ein Zettelkasten, in dem schnell Daten aller Art abgelegt und wiedergefunden werden können. Das verspricht Scribble Papers. Anfangs sieht das Programm sehr spartanisch aus. Aber wenn erst einmal eine kleine Struktur vorhanden ist, erkennt man die große Flexibilität dieses kleinen Helfers.
In jedem Unternehmen mit einem SAP-System gibt es jemanden, der die Verantwortung für die SAP Basis trägt.