Informix Service - Übersicht Standardprodukte
|
|
|
Informix Enterprise Replication ist ein mächtiges Verfahren, um Datenbestände auf verteilte Installationen zu replizieren und konsistent zu halten.
Mit der Version 3.3 unterstützt der Admin-Scout Informix Administratoren bei der Einrichtung, der Konfiguration und dem Monitoring einer Informix Enterprise Replikation.
|
Mit der neuen Version 3.2 wird es möglich, individuelle Benutzer anzulegen. Personalisieren Sie damit den Admin-Scout nach Ihren Bedürfnissen auf der Ebene einzelner Menüpunkte.
Administratoren müssen sich mit Rollen- und Zugriffsrechten von Datenbank-Anwendern befassen. Damit die Prüfung der Rechte eines Anwenders möglich wird, erlaubt die neue Version Zugriffe des SQL-Editors unter einem anderen Benutzernamen zu testen.
Ziel unserer Entwicklung war es die ONCONFIG Variablen an einer Stelle übersichtlich zusammen zu fassen.
Der ONCONFIG Explorer listet alle Variablen alphabetisch sortiert in einer Baumstruktur auf. Alle Informationen zu einer Variablen werden über ein Infopanel angezeigt.
Ein Hilfe Button unterstützt das schnelle Anzeigen der Handbuchreferenz für alle dokumentierten Variablen.
Admin-Scout 3.2 bietet eine vollständige Überarbeitung und Neustrukturierung der Storage Verwaltung. Das neue Modul vereint Storage Administration und Reporting in einem Menüpunkt. Administratoren haben nun alle Storage Objekte über einen hierarchisch sortierten Objektbaum sofort im Blick. Ein einfacher Klick liefert alle relevanten Detailinformationen, sinnvoll über einzelne Reiter organisiert.
Der Admin-Scout 3.2 bietet ein lang erwartetes Feature: den einfachen Vergleich der Strukturen von Datenbanken in unterschiedlichen Instanzen.
Das neue Modul vergleicht nun typische Datenbankobjekte wie Tabellen, Views, externe Tabellen, Sequences Funktionen und die Zugriffsrechte, einschließlich der jeweils zugehörigen Indizes, Constraints und Trigger.
Die gesamte Oberfläche des Admin-Scouts wurde einheitlicher und performanter gestaltet, der Einstieg in Konfiguration und Serververwaltung klar strukturiert. Optimierte Tabellenstrukturen und Skalierung der Darstellung führen zu einem erheblich schnelleren Seitenaufbau.
Die Version 3.0 besticht vor allem durch die neue SQL Toolbox mit vielen leistungsstarken Funktionen im Database Explorer und SQL Editor. Damit bietet der Admin-Scout verstärkt interessante Funktionalitäten für Entwicklung und Tuning von Informix Datenbanken.
Wir haben uns die Frage gestellt, welche Bereiche eines Informix Datenbanksystems müssen manuell administriert werden und wo ist die Einrichtung einer automatisierten Administration möglich. Ziel ist es eine zunehmende Automatisierung und selbständige Optimierung des Systems über ein Wechselspiel von Sensoren und Tasks zu erreichen.
Ein wichtiger Aspekt hierbei ist die Verwaltung der internen Datenbank Prozesse. Ältere Administratoren kennen noch das Einrichten von wiederkehrenden Aufgaben über einen Cronjob. Aktuelle Informix Editionen bieten heute eine eigenständige Verwaltung von Jobs, einschließlich der Erstellung eigener Tasks und Sensoren mit dedizierten Ergebnistabellen und Reports.
Schon in den letzten Versionen hat sich im Admin-Scout vieles um eine Verbesserung der Sicherheit gedreht. Besonders wichtig war es uns, dass während einer Anmeldung keine Passwörter mehr zwischen Admin-Scout und dem Browser übertragen werden.
In der Version 2.3 setzt wir unser Bestreben fort, eine erhöhte Sicherheit gegen das Ausspähen von Daten zwischen Informix Server und Client bzw. dem Admin-Scout zu ermöglichen.
Adobe Flash war jahrelang, dass Mittel der Wahl, um Animationen und anspruchsvolle Grafiken im Browser zu visualisieren. Aus dem Strudel permanenter Sicherheitslücken nicht herausgekommen, wird vor einer Verwendung schon seit langem abgeraten. Auch das Informix OpenAdmin Tool bedient sich in einigen Bereichen des Adobe Flash Players für die grafische Darstellung komplexer Zusammenhänge.
Sicherheitswarnungen und das für 2020 ohnehin angekündigte Supportende für den Adobe Flash Player, haben uns schon früh dazu veranlasst, die grafischen Inhalte des Admin-Scouts über das Dojo Toolkit bzw. HTML5 auszugeben. Sukzessive haben wir alle relevanten Module umgestellt. Damit verbunden war die Neugestaltung aller Charts und das aufwendige Redesigne wichtiger Module wie des SQL-Trace- oder des Storage-Moduls.
|
|
|
Ziel dieses Dokuments ist die Einführung in die Abläufe des CURSOR-Supports. Wir verstehen Support nicht nur als Möglichkeit eine Supportanfrage (Ticket) zu erstellen, sondern darüber hinaus mit Ihnen zu kommunizieren und Ihr Anliegen zu verstehen, weshalb Sie unseren Support kontaktiert haben. Verständnis setzt eine einheitliche Sprache voraus, so dass es wichtig sein wird ein gemeinsames Verständnis über die Prozesse und Begriffe aufzubauen und Rechte und Pflichten zu definieren.
Grundlage für eine zügige Bearbeitung von Tickets ist das entsprechende Know-How der Support-Mitarbeiter. CURSOR dokumentiert dieses Know-How mit entsprechend anerkannten Zertifizierungen. Für den Fall eigener Softwareprodukte, für die keine externen Zertifikate erworben werden können, greift ein qualitativ hochwertiger interner Ausbildungsprozess. Ziel ist ein möglichst breites Wissensspektrum in der Systemumgebung, als auch ein tief gehendes Wissen für die programmspezifischen Komponenten. Praktische Erfahrungen werden in zahlreichen externen Kundenprojekten gesammelt.
Kundenseitig (dies schließt die Partner mit ein) müssen Administratoren zur Verfügung stehen, die sich global mit dem zu betreuenden System und dessen IT-Infrastruktur gut auskennen. Für die Sicherstellung eines effizienten Supports durch die CURSOR Software AG muss zudem ein Basiswissen der unter Wartung stehenden Software vorhanden sein. Die Administratoren müssen in der Lage sein zu entscheiden, ob ein Problem in der unter Wartung stehenden Software oder in der Peripherie begründet liegt. Idealerweise wird das notwendige Know-How durch den Besuch von dedizierten Schulungen oder Zertifizierungen belegt. Dies kann jedoch auch durch praktische Erfahrung zum Ausdruck gebracht werden.
Es ist sicherzustellen, dass die kundenseitigen Systemadministratoren jederzeit über vollen Zugang zu den Systemen mit den notwendigen Rechten verfügen, um eigene oder angewiesene Diagnosen bzw. Fehler-Reproduktionen durchführen zu können. Dieser Umstand, der für die Effizienz des CURSOR-Supports unerlässlich ist, bedingt zudem, dass für die o.g. Zielsetzung dedizierte und qualifizierte Ansprechpartner verfügbar sind. Ein direkter Endanwender-Support kann in erweiterten Supportverträgen übernommen werden. Ideal, jedoch keine Bedingung, ist ein direkter Zugang des CURSOR-Supports zu den unter Wartung stehenden Systemen.
Treten Ereignisse auf, die eine Störung bzw. Minderung der Servicequalität der unter Wartung stehenden Softwarekomponenten zur Folge haben, meldet der Kunde dieses Ereignis dem CURSOR-Support über Mail oder Telefon (Hotline). Als Störung kann vom Prinzip her auch eine mögliche Beeinträchtigung der Servicequalität angesehen werden, so dass nicht nur bereits eingetretene Ereignisse gemeldet werden können, sondern eine präventive Störungsbearbeitung denkbar ist.
Bei der Meldung eines derartigen Ereignisses an der CURSOR-Support-Hotline wird ein sogenanntes Ticket eröffnet mit dem Ziel die zugrunde liegende Störung effizient und dauerhaft zu beheben. Das Ticket wird mit einer eindeutigen Ticketnummer versehen und enthält sämtliche Vorgänge, Dokumente und Korrespondenz zwischen den beteiligten Personen und Institutionen. Im Vorfeld der Ticketbearbeitung hat der Ansprechpartner des Kunden dafür Sorge zu tragen, dass der CURSOR-Support sämtliche notwendigen Informationen für eine Einschätzung der Dringlichkeit (Prioritätsstufe), sowie eine ausführliche Störungsbeschreibung erhält. Der Status des Ticket kann im Ticketportal der CURSOR-Webseite eingesehen werden.
Die eingehenden Tickets, werden nach Prioritäten abgearbeitet. Dabei wird eine max. Reaktionszeit in Relation zur Priorität zugesichert in der aktiv mit der Bearbeitung des Tickets begonnen wird. Die Priorisierung wird bei der Eröffnung des Tickets durch den Kunden vorgenommen, wobei eine Anpassung nach Überprüfung durch den CURSOR-Support möglich ist. Sollte eine Reduzierung der Prioritätsstufe durch den Support erfolgen, wird der Kunde hiervon in Kenntnis gesetzt und die Bearbeitung für die dann geltende Stufe fortgeführt. Es besteht im Anschluss die Möglichkeit in Form einer Eskalation des Tickets die Prioritätsstufe zu erhöhen, sofern der Kunde die erhöhte Dringlichkeit deutlich machen kann.
Prioritätsstufe P1 - Kritische Auswirkungen / System Down
Eine geschäftskritische Softwarekomponente ist ausgefallen oder befindet sich in einem kritischen Status, so dass mit einem Ausfall in Kürze zu rechnen ist. Ausfall heißt, dass die Funktionalität der Softwarekomponente nicht mehr zur Verfügung steht oder die Nutzung geschäftskritische Auswirkungen hat. Die Auswirkungen betreffen eine Vielzahl der Nutzer und benötigen eine umgehende Lösungsfindung.
Zusammenfassend:
Tickets mit Prioritätsstufe P1 müssen telefonisch gemeldet werden. Der CURSOR-Support sichert zu, mit einer Reaktionszeit von max. 2 Supportstunden mit der Bearbeitung des Tickets zu beginnen.
Prioritätsstufe P2 - Erhebliche Auswirkungen
Eine Softwarekomponente ist in der Nutzung und Funktionalität erheblich eingeschränkt. Die Nutzung ist generell möglich, jedoch haben die Einschränkungen signifikante Auswirkungen auf die Geschäftstätigkeit, für die das Programm eingesetzt wird.
Zusammenfassend:
Tickets mit Prioritätsstufe P2 können per Mail oder Telefon gemeldet werden. Der CURSOR-Support sichert zu, mit einer Reaktionszeit von max. 8 Supportstunden mit der Bearbeitung des Tickets zu beginnen.
Prioritätsstufe P3 - Moderate Auswirkungen
Eine Fehlfunktion oder ein Fehlverhalten einer unkritischen Softwarekomponente mit moderaten Auswirkungen auf das Gesamtsystem und Geschäftstätigkeit. Die Softwarekomponenten sind nutzbar und nur leicht in Funktionalität oder Performance eingeschränkt.
Zusammenfassend:
Tickets mit Prioritätsstufe P3 können per Mail oder Telefon gemeldet werden. Der CURSOR-Support sichert zu, mit einer Reaktionszeit von max. 16 Supportstunden mit der Bearbeitung des Tickets zu beginnen.
Prioritätsstufe P4 - Minimale Auswirkungen
Eine Fehlfunktion oder ein Fehlverhalten einer unkritischen Softwarekomponente mit nur geringen Auswirkungen auf das Gesamtsystem und Geschäftstätigkeit ist aufgetreten. Die Softwarekomponenten sind nutzbar und nur gering in Funktionalität oder Performance eingeschränkt oder es wird eine nicht technische Anfrage (Bsp. zur Dokumentation) eröffnet.
Zusammenfassend:
Tickets mit Prioritätsstufe P4 können per Mail oder Telefon gemeldet werden. Der CURSOR-Support sichert zu, mit einer Reaktionszeit von max. 24 Supportstunden mit der Bearbeitung des Tickets zu beginnen.
Prioritätsstufe |
Reaktionszeiten |
---|---|
P1 | 2 Stunden |
P2 | 8 Stunden |
P3 | 16 Stunden |
P4 | 24 Stunden |
Bevor der CURSOR-Support kontaktiert wird, sollten folgende Informationen durch den Kunden zusammengetragen werden:
Sobald diese Informationen verfügbar sind, meldet der Ansprechpartner des Kunden die Störung und erhält nach erfolgreicher Prüfung des Supportanspruches eine persönliche Ticketnummer.
Der Status des Tickets kann im Supportbereich der CURSOR-Webseite jederzeit verfolgt werden. Ein separater Login ist hierfür notwendig.
Nachdem das Ticket gegenüber dem Kunden bestätigt wurde, beginnt innerhalb der definierten Reaktionszeit die Bearbeitung. Innerhalb dieses Prozesses können drei Stufen unterschieden werden:
Phase 1 - Analyse:
Zur Optimierung der Analysephase der Störung ist eine möglichst vollständige Fehlerbeschreibung, inkl. der beschriebenen kundenseitigen Informationen zur Installationsbasis notwendig. Dies hilft Rückfragen zu vermeiden und möglichst direkt die fachkundigsten Mitarbeiter des Supports mit der Analyse zu betrauen.
Ergebnis: Die Ursache der Störung wird festgestellt und ein erstes mögliches Lösungsszenario entwickelt
Phase 2 - Workaround:
Sofern notwendig werden effektive und zuverlässige Maßnahmen getroffen, die die Störung umgehen und somit ein weiteres Arbeiten ermöglichen. Diese Maßnahmen werden nicht dauerhaft implementiert, sondern temporär bis zur endgültigen Behebung des Problems genutzt.
Ergebnis: temporäres Umgehen der Störung zur schnelle Wiederherstellung der Betriebsbereitschaft
Phase 3 - Behebung:
Die Ursache der Störung wird durch Maßnahmen behoben, die dauerhaft implementiert werden. Sie stellen die volle Servicequalität wieder her, mit der Zielsetzung das System stabil und performant zu betreiben.
Ergebnis: dauerhafte stabile und performante Implementierung der Lösung
Auf Grundlage der beschriebenen Reaktionszeiten (siehe Prioritätsstufen) wird der Prozess effizient durchlaufen. Störungen in dem Ablauf werden durch einen Eskalationsprozess begleitet, der durch den Eskalationsmanager beaufsichtigt wird. Er garantiert die situationsbezogene optimale Abarbeitung der drei Phasen der Ticketbearbeitung.
Ist Phase 3, also die Behebung der Ursache mit einer dauerhaften, stabilen und performanten Lösung durch den Kunden bestätigt, kann das Ticket in den Status „Erledigt“ überführt und somit geschlossen werden.
Im Fall eines Software-Fehlers (Bug) wird das Ticket an die interne Entwicklungsabteilung bzw. an den Hersteller der Software gemeldet. Eine entsprechende Priorisierung richtet sich nach der vom Kunden gemeldeten und vom CURSOR-Support verifizierten Einstufung.
Liegt die Ursache der Störung nach Abschluss der Phase 1 nicht in der unter Wartung stehenden Software, wird der CURSOR-Support dies dem Ansprechpartner des Kunden mitteilen und das Ticket schließen.
Werden die internen Vorgaben zur Ticketbearbeitung nicht eingehalten bzw. die definierten Reaktionszeiten überschritten, greift automatisch ein interner Eskalationsprozess mit der Zielsetzung die Ursache für die Verzögerung zu ermitteln und zu beheben.
Darüber hinaus hat der Kunde die Möglichkeit eine Eskalation anzustoßen, wenn die Ticketbearbeitung bzw. die Einstufung der Priorität der Störung durch den CURSOR-Support nicht seinen Geschäftsanforderungen entspricht. Die Eskalation wird durch den Eskalationsbeauftragten überwacht und erst abgeschlossen, wenn eine einvernehmliche Lösung gefunden wurde. Sie ist spätestens dann beendet, wenn Phase 3 der Ticketbearbeitung abgeschlossen und durch den Kunden bestätigt wurde. Eine Eskalation kann ausgelöst werden, wenn eine Mail mit der Ticketnummer, gefolgt von den Signalwort "ESKALATION" an die Hotline gesendet wird. Alternativ dazu kann der Kunde über die Telefonhotline die Eskalation direkt anstoßen. Wir empfehlen jedoch die Auslösung schriftlich zu begründen, damit der CURSOR-Support zeitnah die Möglichkeit erhält auf die Kritik reagieren zu können.
Der Eskalationsbeauftragte wird sich unmittelbar mit dem Kunden in Verbindung setzen nachdem er die kritisierten Aspekte und die Bearbeitung des Tickets überprüft hat.
Zum besseren Verständnis des Supportprozesses ist die Darstellung von möglichen Zustandsübergängen sehr hilfreich. Im weiteren Verlauf werden die einzelnen Stati erläutert.
Die Bearbeitung des Tickets hat noch nicht begonnen. Der Status wird gesetzt, wenn der Kunde das Ticket eröffnet, sei es telefonisch oder per Mail und die Legitimationsprüfung positiv abgeschlossen wurde. Das Senden einer Bestätigungsmail mit der zugehörigen Ticketnummer bedingt noch keinen Statuswechsel. Der nächstmögliche Statuswechsel ist nach „In Bearbeitung“ möglich. Er ist der Indikator für die Einhaltung der definierten Reaktionszeiten, wie sie in dem Prioritätsbeschreibungen enthalten sind. Darüber hinaus gehende, kundenindividuelle Service-Level bedingen ggfs. kürzere Reaktionszeiten.
Der Status „In Bearbeitung“ wird gesetzt, wenn aktiv an dem Ticket gearbeitet wird. Dies gilt auch dann, wenn CURSOR-intern Rückfragen gestellt werden und daher vom Prinzip her potenzielle inaktive Zeiten entstehen. Akkumuliert dokumentiert der Status die Zeit, in der der CURSOR-Support mit der Bearbeitung beschäftigt ist. Möglicher Statusübergang nach „Warten auf Kundenrückmeldung“, „Warten auf Herstellerrückmeldung“, „Erledigt“ und "Ruhend sind möglich.
Nachdem das Ticket „In Bearbeitung“ war, kann es auf „Warten auf Kundenrückmeldung“ gesetzt werden. Dies kann erfolgen, wenn dem Kunden eine Statusmail mit dem aktuellen Bearbeitungsstand, sowie der Aufforderung gesendet wird, weitere Informationen zu liefern. Notwendige Informationen können weitere Tests, Dokumentationen, Protokolldateien etc. sein. Eine fristgerechte Reaktion des Kunden wird vom CURSOR-Support überwacht. Nach zwei Tagen wird der Kunde an ausstehende Informationen erinnert, sofern keine andere Frist vereinbart wurde. Liegt nach wiederholter Erinnerung bzw. nach sechs Tagen keine Reaktion vor, wird der Wartungsfall geschlossen. Eine Wiederaufnahme ist jederzeit möglich.
Für den Fall, dass der Kunde einen Grund für mögliche Verzögerungen liefert (bspw. Urlaub, Krankheit etc.) kann das Ticket für den absehbaren Zeitraum auf „Ruhend“ gesetzt werden.
Mögliche Statusübergänge auf „In Bearbeitung“, „Ruhend“, „Erledigt“.
Bei Bedarf kann der CURSOR-Support einen Wartungsfall bei dem Hersteller eröffnen. Nachdem der Ticket-Status „In Bearbeitung“ war, kann er auf „Warten auf Herstellerrückmeldung“ gesetzt werden. Der Kunde erhält in diesem Fall eine Statusmail mit dem aktuellen Bearbeitungsstand und den Hinweis, dass der Hersteller (bspw. IBM) eingeschaltet wurde. Eine fristgerechte Reaktion des Herstellers wird vom CURSOR-Support überwacht. Mögliche Statusübergänge auf „In Bearbeitung“, „Ruhend“, „Erledigt" sind möglich.
Der Status „Ruhend“ kennzeichnet eine inaktive Phase der Ticketbearbeitung. Mögliche Gründe sind Krankheit oder Urlaub des anfragenden Kunden, so dass das Ticket temporär nicht bearbeitet werden kann. Auch wenn bestimmte Situationen eintreten, die eine Bearbeitung des Wartungsfalles verhindern (Problem kann aktuell nicht reproduziert werden, Testsystem steht nicht zur Verfügung, Vorbereitungen zum Monatsabschluss lassen Tests nicht zu etc.). Zu einem Ticket mit dem Status "Ruhend" ist ein Ereignis zu überwachen, das diesen Status beendet. Dies kann zum Beispiel ein bereits zu Beginn bekanntes Datum (Urlaubsende, erneuter Testbeginn) sein. Der CURSOR-Support überwacht den Fristablauf oder die abhängigen Ereignisse und informiert den Kunden umgehend. Eine weitere Möglichkeit das Ticket auf „Ruhend“ zu stellen ist ein mögliches zeitlich definiertes Fixpack durch den Hersteller bzw. durch die CURSOR-Entwicklungsabteilung. Mögliche Statusübergänge auf „In Bearbeitung“, „Erledigt“.
Der Status „Erledigt“ kennzeichnet das Ende der Ticketbearbeitung. Über den Lösungsstatus ist zu beschreiben, mit welchem Ergebnis das Ticket abgeschlossen wurde. Tickets mit diesem Status werden nicht mehr überwacht. Eine Beschreibung der Lösung wird dem Kunden mit Abschluss des Wartungsfalles kommuniziert.
Mögliche Statusübergänge auf „Wiederaufnahme“.
Der Status „Wiederaufnahme“ hat vom Prinzip her den gleichen Charakter, wie der Status „Offen“, mit dem einzigen Unterschied, dass hier ein Ticket voranging und bereits eine Bearbeitungshistorie aufweist. Auch hier ist der mögliche Statusübergang zu „In Bearbeitung“ ein Indikator für die Reaktionszeit.
Für den Kundenzugang zu den Service-Leistungen stehen generell drei Wege zur Verfügung (Telefon, Internet und Email)
Montag bis Freitag von 8 Uhr bis 17 Uhr (ausgenommen bundeseinheitliche Feiertage oder nach individueller vertraglicher Vereinbarung)
Internet | Art | Beschreibung |
---|---|---|
http://www.cursor-distribution.de/ticketportal | Internet |
|
Telefon | Art | Beschreibung |
---|---|---|
+49 641 40000 - 333 | Telefon | Zentrale Nummer für eingehende Support-Anfragen per Telefon während der Standard-Supportzeiten |
wird bei Buchung mitgeteilt | Telefon | Hotline für 7 x 24 Std.-Support, außerhalb der Standard-Supportzeiten |
Art | Beschreibung | |
---|---|---|
|
Support-Kontaktadresse für den kompletten IBM-Support der CURSOR-Distribution | |
|
Sind ebenso möglich. |
Auf Basis der geschilderten Standards im Support der CURSOR AG können weitergehende Anforderungen seitens des Kunden oder Partners erforderlich sein. Dazu werden Konzepte zur Verfügung gestellt, die diese Anforderungen so weit wie möglich auf einem möglichst standardisierten Vorgehen abdecken. Hierzu wird ein aufeinander aufbauendes Stufenmodell angeboten.
Grundlagen und Zielsetzung
Für geschäftskritische Anwendungen oder im Mehrschichtbetrieb ist es empfehlenswert die Standardsupportzeiten auf 7x24 Std. inkl. Sonn- und Feiertage auszudehnen. Die Standard-Supportzeiten, werden entsprechend für Tickets der Prioritätsstufe P1 auf 7x24 Std. inkl. aller Sonn- und Feiertage erweitert. Für Tickets mit anderen Prioritäten bleibt es bei den definierten Supportzeiten.
Der CURSOR-Support stellt für die erweiterten Supportzeiten eine Telefonnummer zu Verfügung, die von der gewohnten Support-Telefonnummer abweichen kann. Hier wird ein deutschsprachiger und entsprechend qualifizierter Mitarbeiter das entgegen nehmen und entsprechend der definierten Reaktionszeit bearbeiten.
Im Verlauf der Ticket-Bearbeitung kann es notwendig werden, dass sich der CURSOR-Support-Mitarbeiter oder ein Mitarbeiter des Software-Herstellers auf das Kundensystem aufschaltet, um dort die Ticket-Ursache besser analysieren und ggfs. beheben zu können. Sollte das System derart korrupt sein, dass es gepatched werden muss, bleibt dies aufgrund wartungsrechtlicher Vorgaben dem Hersteller vorbehalten. Die schriftliche Genehmigung für den Login kann fallweise oder generell erfolgen. Sollte ein Login nicht erlaubt oder möglich sein, beschränkt sich der Support auf die telefonische Unterstützung.
Aufgrund der besonderen Bedeutung geschäftskritischer Anwendungen bietet die CURSOR AG gebündelt mit der Erweiterung auf 7x24 Std. eine monatliche Überprüfung der unter Wartung stehenden Softwareinstallationen an. Diese präventive Beobachtung potenzieller Engpässe senkt das Ausfallrisiko dramatisch, so dass im Sinne des Kunden Ausfälle deutlich seltener auftreten und damit Kosten und Imageverlust vermieden werden. Eine Erweiterung auf 7x24 Std. ist losgelöst von der regelmäßigen Überprüfung möglich. Je nach Produkt wird dem Kunden bzw. ISV ein Tool zum Sammeln von Daten zur Verfügung gestellt bzw. ein Leitfaden kommuniziert, welche Informationen für die Überprüfung benötigt werden. Ein Login auf das Kundensystem ist nicht notwendig. Nähere Informationen finden Sie unter: http://www.cursor-distribution.de/dienstleistungen/premium-support-7x24-praeventiv
Eine Erweiterung der Ausfall-Prävention ist die Remote-Systemadministration. Darin übernehmen wir auf Basis fest vereinbarter Konditionen die Arbeiten eines Administrators zur Sicherstellung des kundenseitigen Datenbankbetriebs. Hier lassen sich eine Vielzahl von möglichen Szenarien beschreiben, die kundenseitig von Vorteil sind. Bitte sprechen Sie uns bezüglich Ihrer Anforderungen an.
Die Bereitstellung von Software erfolgt bei der CURSOR AG grundsätzlich per Download im internen Supportbereich unserer Webseiten. Der Kunde erhält auf Basis seines Vertrages einen Zugang mit angepassten Download-Rechten. Bugfixes, Patches etc. werden im gleichen Portal durch entsprechende Release-Nummer gekennzeichnet. Der Support-Mitarbeiter wird den Kunden auf das entsprechende Release hinweisen.
Zudem hat der Kunde die Möglichkeit über eine eigene Bugrecherche auf unserer Webseite das entsprechende Fixpack zu identifizieren und herunter zu laden. Dieser Service steht auch für die Standard-Supportverträge rund um die Uhr zur Verfügung. Sollte ein Download nicht verfügbar sein, kann dieser per Mail oder Telefon beim Support angefordert werden.
IBM Informix V14.10 Dokumentation ist jetzt online im IBM Knowledge Center verfügbar.
Hier klicken und die Dokumentation einsehen.
Topics:Performanz
Administration
Sicherheit
Erweiterungen
Installation
|
|
Informix Dynamic Server Dokumentations-CD (gezippt):
Docu-CD-IDS12.10.xC1 (79.74 MB)
Doku-CD-IDS12.10.xC2 (59.11 MB)
Docu-CD-IDS12.10.xC4W1 (59.5 MB)
Doku-CD-IDS12.10.xC6 (82 MB)
Eine Liste aller verfügbaren Dokumentationen, auch in anderen Sprachen, finden Sie bei der IBM.
Inhalt der aktuellen Dokumentations-CD 12.10.xC6 als Einzeldokumente:
Informix Dynamic Server Dokumentations-CD (gezippt):
Eine Liste aller verfügbaren Dokumentationen, auch in anderen Sprachen, finden Sie bei der IBM.
Inhalt der aktuellen Dokumentations-CD 11.70.xC8 als Einzeldokumente:
|