GEAC-Hinweise - Wie Man

GEAC-Hinweise

Johns GEAC & FRX Hinweise

8 Schritte insgesamt

Schritt 1: GEAC / FRX-Verarbeitungsverfahren

Datenbank zu groß:

Am Dienstag, dem 8. Mai, trat ich in einer ProfitMark-Besprechung auf. James trat ein und gab an, dass Probleme mit den Terminalservern gemeldet wurden. Auf dem Weg zu meinem Büro hielt mich Sharon an. Sie gab an, dass sich Leute über Probleme mit dem GEAC beschwerten. Ich ging zu meinem Schreibtisch, um mir die Dinge anzusehen. Mir wurde sofort klar, dass es kein Problem mit den Terminalservern gab. Dann habe ich einen Blick auf GEAC oder den SQL-Server geworfen. Ich habe mir die Leistung der Maschine und die Leistung von SQL angesehen und das Problem nicht gefunden. Ich ging dann in die AP-Abteilung, um zu klären, was schief gehen könnte. Mir wurde klar, dass das Problem darin bestand, dass einige Transaktionen nicht vollständig verarbeitet wurden. Da es keine Probleme mit den Terminalservern gab und es offenbar kein Problem mit dem SQL-Server gab, stellte ich fest, dass es am besten wäre, alle Systeme neu zu starten. Wir haben eine Notiz gesendet, die besagt, dass wir in 30 Minuten einen Neustart durchführen würden und die Benutzer bis zur Benachrichtigung draußen bleiben sollten. Beim Neustart des Systems bestand das Problem weiterhin. Ich hatte ein paar Leute in der AP-Abteilung, die alles testeten, um sicherzustellen, dass es immer noch ein Problem gab. Zu diesem Zeitpunkt haben wir eine Supportanfrage von Biznet gesendet. Ich ging dann zurück an meinen Schreibtisch, um mir den SQL-Server genau anzuschauen, um zu sehen, ob ich feststellen konnte, was das Problem verursachen könnte. Da es sich bei dem Problem hauptsächlich um einige Datenbanken handelte, konzentrierte ich mich zunächst auf diese Datenbanken. Ich habe mir zuerst die gesamte AP-Datenbank angesehen, die mit dem Problem in Verbindung steht, und nichts gefunden, was mit ihnen zu tun hat. Dann habe ich mir die GLUSD-Datenbank und ihre Konfiguration sehr genau angesehen, da dies die meisten Probleme war, wenn Transaktionen gebucht wurden. Ich habe mir alle Parameter und Einstellungen genau angesehen. Bei einem Blick auf das System konnte ich feststellen, dass für Datenbankdateien, insbesondere für den Datenbanknamen "GLUSDB_Data.dbf", eine maximale Größe von 49 MB festgelegt wurde. Die Datenbank war auf 45 MB angewachsen. Ich habe diese bestimmte Datenbank automatisch anwachsen lassen, da die Größenbeschränkung nicht benötigt wurde. Da wir bereits alle Server neu gestartet hatten, mussten wir erneut warten, bis alle Server außer Betrieb waren. Als ich sicher war, dass alle außer Betrieb waren, startete ich alle Server neu. Ich dachte, wir hätten eine lokale Installation des GEAC Sharon-Computers zum Testen, aber sie gab an, dass sie keine lokale Installation hatte. Also habe ich den Terminalserver 1 eingeschaltet und wir haben mit dem Testen auf den Rechnern von Vi und Maria begonnen. Wir haben den Computer von Vi hauptsächlich verwendet, weil Biznet aus diesem Grund getestet hatte. Als wir diesmal alle Transaktionen getestet hatten, wurde die Verarbeitung ordnungsgemäß gestartet. Wir haben ungefähr vier Tests bei Vi’s Computer durchgeführt und ungefähr vier Tests bei Marie diesem Computer. Ich ging dann zu Sharon und Nancy und beide testeten die Prozesse, die sie durchgeführt hatten. Es scheint, dass alle Prozesse gut funktionierten. An diesem Punkt habe ich beschlossen, eine E-Mail zu senden, um alle wissen zu lassen, dass sie jetzt wieder in das System einsteigen können. Da wir keine größeren Probleme mit der Anwendung oder größere Leistungsprobleme auf dem Server festgestellt haben, haben wir festgestellt, dass das Problem möglicherweise mit der Datenbank verbunden war, die nicht anwuchs. Als ich am nächsten Morgen kam, habe ich mit ein paar Leuten gesprochen, um sicherzustellen, dass sie gut funktionieren. Am nächsten Tag ist es jetzt 15.00 Uhr, und niemand hat größere Probleme im System gemeldet.

Schritt 2: Probleme bei der Verarbeitung von GEAC / FRX

Samas oben Ausgabe:

Wenn GEAC keinen vom Buchhalter erstellten Job buchen wird. Sie versuchen, das Ticket zu buchen, und der Vorgang hängt und es dauert über 4 Minuten, bis der Vorgang abgeschlossen ist. Sofort muss jeder aufhören zu posten und das System zu verlassen. Die Latenzzeit auf dem Laufwerk inVMWare und die Verlangsamung des Servers haben die Verarbeitung abgeschlossen. Sobald eine Nachricht an alle Benutzer gesendet wurde, die nach 30 Minuten eine Verbindung zu den Terminalservern herstellen, sollte der Zugriff auf die Terminalserver gestoppt werden. Nachdem der Zugriff gestoppt wurde, kann es sinnvoll sein, den SQL-Server neu zu starten. Nachdem der Server neu gestartet wurde, muss jemand im Home Office den Prozess von einer VMWare-Verbindung zu einem der Terminalserver versuchen. Wenn der Vorgang erneut ordnungsgemäß ausgeführt wurde, können Sie den Zugriff auf die Terminalserver wieder aktivieren. Die Probleme sollten jetzt behoben werden.

Schritt 3: FRX-Probleme

Die Verarbeitung von Berichten im Report Launcher schlägt mit diesem Fehler im QUE-Statusfenster fehl.

Benutzer-Standarddatenbank kann nicht geöffnet werden.

Dies geschah, als wir die Datenbanken auf den neuen Server kopierten. Die meisten Benutzer werden ihrer Eigenschaftsdatenbank nicht standardmäßig zugewiesen. Um das Problem zu beheben, muss die Eigenschaftendatenbank des Benutzers in HHGSQL3 als Standard festgelegt werden. Bei mehreren Eigenschaften den GLUSD als Standard festlegen.

Schritt 4: NetExtender Down

12-05-12 NetExtender ist inaktiv. Hier sind meine Notizen zu meinen Reparaturschritten.

Ich habe untersucht, was heute morgen ein Problem mit dem SSL-VPN verursacht haben kann. Kurz bevor ich gezwungen war, das VPN 4000 heute Morgen neu zu starten, stelle ich fest, dass die Protokolle Datum und Uhrzeit falsch anzeigen. Beim Überprüfen der Zeiteinstellungen habe ich die in der Appliance eingerichteten NTP-Server überprüft und festgestellt, dass sie nicht mehr aktiv sind. Ich habe drei neue NTP-Server anstelle von zwei festgelegt, da dies zulässig ist, und sichergestellt ist, dass sie die Uhrzeit tatsächlich einstellen. Ich habe auch den NTP-Check von einmal pro Stunde auf einmal täglich erhöht, da die Uhr nicht so oft überprüft werden muss. Ich hoffe, das hilft unseren aktuellen Ausgaben.

user = "jthompson" usr = "jthompson" msg = "NetExtender" Regel = Zugriffsrichtlinie proto = NetExtender-Agent = "SonicWALL NetExtender für Windows 4.0.134 (kompatibel; MSIE 7.0; Windows NT 6.0; SLCC1)" 24. Aug. 15 15: 05:03 hostmarkvpn SSLVPN: id = sslvpn sn = 0006B13DACE8 Zeit = "2012-08-24 15:05:03" vp_time = "2012-08-24 20:05:03 UTC" fw = 10.16.3.215 pri = 2 m = 0c = 701 src = 10,16,0,34 dst = 10,16,3,215

user = "admin" usr = "admin" msg = "SSLVPN wurde neu gestartet" agent = "Mozilla / 5.0 (kompatibel; MSIE 9.0; Windows NT 6.1; WOW64; Trident / 5.0)" 5. Dezember 09:22:22 hostmarkvpn SSLVPN: id = sslvpn sn = 0006B13DACE8 Zeit = "2012-12-05 09:22:22" vp_time = "2012-12-05 15:22:22 UTC" fw = 10.16.3.215 pri = 4 m = 1 c = 1 src = 74,84,89,57 dst = 10,16,3,216

Schritt 5: GEAC-Leistungsproblem

12-06-12 Die Leute fingen an, sich zu beschweren, dass GEAC heute langsam sei. Ich habe keine Fehler am Server gefunden. Ich entschied mich für einen Neustart der beteiligten Server. Der Neustart hat das Problem nicht behoben. Ich entschied mich für ein Mitternachtsstillstand und eine Diagnose der Systeme. Hier meine Notizen: Ich möchte Sie über meine Diagnose der GEAC-Datenbankprobleme auf den neuesten Stand bringen, die alle gestern gemeldet haben. Da unser Nachmittagsneustart des Servers das Problem nicht gelöst hat, habe ich beschlossen, das Problem zu untersuchen, wenn alle abwesend waren. Wie Sie wissen, habe ich bis Mitternacht gewartet und das Problem genauer untersucht. Ich habe keine Probleme auf dem GEAC-Server entdeckt. Ich habe einen Fehler in TS02 gefunden. Ich führte Windows-Updates auf beiden Terminalservern durch und TS02 hatte keine Fehler mehr. Ich stelle den Zugriff auf alle Server wieder her, wenn ich fertig war. Ich habe heute morgen mit Maria gesprochen, und sie gab an, dass sie alle ihre Prozesse durchlaufen hatte und kein Leistungsproblem hatte. Ich habe das System heute Morgen um 7:30 Uhr beobachtet und habe das Leistungsproblem, das ich gestern gesehen habe, nicht gesehen. Ich möchte, dass Sie mich sofort benachrichtigen, wenn Sie oder Ihre Immobilien heute Probleme haben. Nach der Mitternachtsaufräumung hat alles gut funktioniert.

Schritt 6: FRX-Probleme

12-10-12 Menschen melden heute Morgen Probleme mit FRX. Sie erhalten die Meldung "(WriteQueueData) Error: 0", wenn sie versuchen, Berichte auszuführen. Ich habe diese Nachricht auf der Microsoft-Support-Website gefunden. "Dies weist normalerweise darauf hin, dass in Great Plains kein volles aktuelles Jahr eingerichtet ist. Die Zeitraumangaben beziehen sich nicht auf ein vollständiges Jahr oder darauf, dass es sich nicht um aufeinander folgende Daten handelt. Berechnen Sie ein vollständiges Jahr in Great Plains (Setup | Company | Fiscal Periods). Benennen Sie anschließend alle * .g32-Dateien um, die sich im FRx SysData-Verzeichnis befinden, während FRx Reporter und Report Launcher geschlossen sind. Starten Sie anschließend den Bericht und erstellen Sie ihn. " Ich habe von den Mitarbeitern herausgefunden, dass es am Wochenende eine Art Datumsänderung der Daten gab. Ich habe den FRX-Server neu gestartet, in der Hoffnung, alle erforderlichen Datumsänderungen zu synchronisieren und damit den Fehler zu beheben.

Schritt 7: Server heruntergefahren

Der GEAC-Server antwortet heute Morgen nicht. Ich konnte keine genauen Informationen zu den heutigen Fehlern finden. Am Ende habe ich beide Terminalserver ausgeschaltet und den Datenbankserver neu gestartet. Dies scheint zu passieren, wenn auf dem Server ein gesperrter Prozess angezeigt wird. Dies ist die Art von Bedingung, die auftritt, wenn ein Benutzer die Verbindung zum Terminalserver unterbricht, ohne GEAC zu verlassen. Durch diese Aktion bleibt die Datenbank für den Benutzer geöffnet und gesperrt.

Schritt 8: Fehler beim Benutzerzugriff

12-21-12 - Ich habe den Server heute morgen überprüft, als Leute berichteten, dass sie Probleme mit GEAC und normalen Benutzerdaten hatten. Ich fand die GEAC-Benutzer beschwerten sich über den Zugriff auf Dateien oder den Server, aber nicht wirklich GEAC-Datenbanken. Ich hatte einige Benutzer, die sich vom TS abmeldeten und wieder anstellten. Dies korrigierte ihre Zugriffsprobleme. Es gab immer noch Benutzer, die sich beschwerten, und als ich den Dateiserver genauer unter die Lupe nahm, bemerkte ich, dass sich der Server über die Ausführung eines "chkdsk" auf den lokalen Laufwerken beschwert. Ich entschied, dass es am besten ist, alle aus den Terminalservern herauszuholen, bevor ich die "chkdsk" laufen ließ. Es dauerte ungefähr 20 Minuten, um "chkdsk" auszuführen und den Server neu zu starten. Ich sandte Nachrichten aus und ging durch das Büro, um Benutzer von den Servern zu überzeugen. Als der Neustart abgeschlossen war und alle miteinander verbunden waren, erlebten wir an diesem Tag keine Fehler mehr.


5dfa0e0c654de3df950c8cf11c9e4b36a20bbea04c5f4e7a45519a3154cbb28c_Server_Errors.txt