Pervasive SQL / Btrieve Errorcodes

Actian / Pervasive Dokumentation
Actian / Pervasive V15 Status / Error Codes

3115: Actian Zen / Pervasive / Btrieve

Fehlermeldung:
Beim starten des IFW erschein die Fehlernummer 3115. 3115 Pervasive Network Services Layer encountered a transport failure. Ursache:
Pervasive / Btrieve kann keine Verbindung zur Datenbankengine aufbauen. Entwender sind die benötigten Ports nicht geöffnet oder die DNS Namensauflösung findet den Server nicht. Abhilfe
Pervasive SQL verwendet die TCP/IP Ports 3351/tcp und 1583/tcp. Siehe http://supportservices.actian.com/kb/. oder geben Sie in der etc/hosts die IP des Datenbankservers an.

Actian / Pervasive PSQL Licence Key Reparatur

Die PSQL Lizenz hat Status "failed validation" oder "disabled" angenommen:
Seit PSQL v11 SP3 gibt es dazu ein "Repair-Tool". Mit diesem können Sie bis zu 5-mal Ihre Lizenz wieder reparieren und neu aktivieren. Bitte starten Sie dazu den Pervasive Software License Administrator.
Wählen Sie zur Reparatur den entsprechenden Key aus und klicken Sie rechts unten, auf "Repair".
Sollten Sie das Servicepack 3 noch nicht installiert haben wenden Sie sich an Ihren Systembetreuer.
Wieso wird ein Key überhaupt inaktiv?
Seit PSQL v10 wurde ein Lizenzsystem eingeführt, bei dem jede PSQL Engine nur auf einer Maschine installiert werden kann. Dies wird dadurch gewährleistet, dass bei dem Authorisierungsprozess Informationen über die physische oder virtuelle Maschine abgefragt werden und damit eine eindeutige Signatur der Maschine erstellt wird. Diese Signatur wird lokal und im Lizenzserver bei Pervasive gespeichert.
Jedes Mal, wenn die Pervasive PSQL ausgeführt wird, wird ein "validation check" ausgeführt. Dieser vergleicht die aktuelle Maschinensignatur mit der bei der Lizenzierung hinterlegten Signatur. Sollten sie übereinstimmen, bleibt die Lizenz aktiv, ist sie hingegen abweichend (beispielsweise nach Änderungen an der Hardware), wird die Lizenz inaktiv. In diesem Fall ist es mit einer einfachen Deautorisierung nicht getan: Es ist dann eine Reparatur nötig, um die Lizenz wieder aktivieren zu können.
WICHTIG: Da bei einer Reparatur eine neue Signatur erstellt wird, und diese auch im Pervasive Lizenzserver hinterlegt wird, muss eine Internetverbindung hergestellt sein. Beachten Sie bitte auch, dass die Reparaturvorgänge auf maximal 5 begrenzt sind.

MKDE-2039: System Error: 612.0.-1, Actian Zen PSQL V13

Im Logbuch pvsw.log steht folgende Meldung:

27.03.2020 15:26:50 MKDE 6604 NTDBSMGR64.EXE KWT-Files E MKDE-2039: System Error: 612.0.-1
27.03.2020 15:46:21 MKDE 6604 NTDBSMGR64.EXE KWT-Files E MKDE-2039: System Error: 612.0.-1
27.03.2020 15:47:50 MKDE 6604 NTDBSMGR64.EXE KWT-Files E MKDE-2039: System Error: 612.0.-1

Abhilfe:

Installation der neusten Version. Sie Patchnote: http://esdftp.actian.com/~CEINXu/PSQLv13_31_patch_readme.html (System Error 612.0.-1 may be generated in PVSW.LOG when accessing files on a 4K sector disk.)

PSQL startet nicht. Actian Zen PSQL V13

Nach einem geplanten Serverneustart zur Installation von Windows Updates starten die Dienste "Actian PSQL Relational Engine" und "Actian PSQL Transactional Engine" nicht korrekt. Die Dienste stehen auf dem Status "wird gestartet", jedoch starten Sie nicht.

27.03.2020 20:00:26 MKDE 6604 NTDBSMGR64.EXE KWT-Files I MKDE-2148: PSQL VSS Writer state: Frozen
27.03.2020 20:00:27 MKDE 6604 NTDBSMGR64.EXE KWT-Files I MKDE-2148: PSQL VSS Writer state: Thawed
28.03.2020 20:00:17 MKDE 6604 NTDBSMGR64.EXE KWT-Files I MKDE-2148: PSQL VSS Writer state: Frozen
28.03.2020 20:00:17 MKDE 6604 NTDBSMGR64.EXE KWT-Files I MKDE-2148: PSQL VSS Writer state: Thawed
29.03.2020 20:00:30 MKDE 6604 NTDBSMGR64.EXE KWT-Files I MKDE-2148: PSQL VSS Writer state: Frozen
29.03.2020 20:00:30 MKDE 6604 NTDBSMGR64.EXE KWT-Files I MKDE-2148: PSQL VSS Writer state: Thawed

Abhilfe:

Die einzige z.Zt bekannte Lösung dieses Problem zu beheben ist, die Dienste erneut zu starten oder den Server neu zu booten.

Error 3006

Answer Goldstar-Software Bill Bach

"Status 3006 is typically a secondary error, caused after a network failure drops the connection. This is common if the PC is not being used for a long time, goes to sleep (or puts the NIC to sleep), and when it wakes up, the server thinks the client is long gone. Sometimes this can be addressed by enabling Auto-Reconnect on the Server and PSQL Client, but not always. You may have to disable power management on the PC (or set to high performance) instead.

Another possible issue is with some PC's (especially from Dell) and RealTek network cards. Microsoft released a faulty driver for various versions of Windows for the RealTek NICs, and I have seen these cards cause endless problems with exactly the symptoms you mention. Swap out the NIC or upgrade the driver to one from RealTek's web site, and this problem goes away.

It might be helpful to confirm the exact exception, too. Check the Windows Event log and post the complete message you see from the software exception. The exception type, module, and location may be beneficial in determining what is going on.

If all else fails, monitoring a PC's connection with Wireshark can yield information about what is truely happening under the covers…."

Statement Customer Girish Duddu

"We have enabled Auto Reconnect option both on the server and client side.

The exact exception that we get is "External exception C0000006". In the Pervasive database server log "C:\ProgramData\Actian\PSQL\logs\pvsw.log" we see the following session timeout errors which are repeating for each client PC …"

Answer Goldstar-Software Bill Bach

Ahh – the dreadded "In-Page I/O Error"! This error appears when an application EXE file or DLL is loaded across a network connection, but the network connection is lost (or disconnected) and cannot be re-established when the application attempts to read more data from the EXE/DLL file.

I am afraid to tell you that this is a common Windows issue, usually caused by network outages. Your search through the Windows Event Logs must have missed it – every InPage I/O Error is logged by the OS there! Were you looking on the workstations or on the server?

I have seen a few possible causes of this type of outage:

1) Power Saving Mode kicking in on the client or server, limiting network traffic. This is indicated if the problems happen after a computer is idle for a time period.

2) Extremely busy network traffic on a LAN segment, preventing communications for a long period of time. (With PARC disabled, 10-15 seconds is enough – with PARC enabled, though it should take 3 minutes.) This can happen at any time, but especially while backups are running.

3) Suspension of a virtual machine, due to either backup via an external tool (e.g. Veeam) or vMotion (which can also cause a LAN overload). This can also happen any time, especially on VM environments.

4) Failing DHCP renewals. This can happen with a short DHCP lease and a renewal process that is not working. The Windows Event Logs should ALSO indicate that the IP address has been released, and if it takes more than 10 seconds to renew, all hel1 breaks loose. This can easily be seen if you monitor a problem workstation via a network analyzer – you can actually see the DHCP renewals returning NAK and the IP address getting freed up, killing EVERY TCP connection, including both the database AND the windows sessions.

5) Windows Sessions getting disconnected. You can disable the Windows SMB disconnect via registry settings (search the web for "0xC0000006" and you'll get solutions there. Clearly the sessions are getting disconnected.

While you can eliminate the InPage I/O Error by moving the application locally, the loss of the TCP connection for the database cannot be fixed. I would start by capturing a network trace (with Wireshark) on a workstation experiencing the problem, and you should see EXACTLY what is happening when the failure appears.