Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Can't figure out why the db keeps going down at least 3 times a week

Status
Not open for further replies.

wvotta

MIS
Aug 19, 2009
31
US
I have an opportunity to finally troubleshoot this terrible issue. We have, at least 3 times a week, a problem where our pervasive db goes into a bad state and gives our Max users all kinds of errors until we restart the db services on the Windows 2000 server running Pervasive 8.7 sp3 (as are the clients). Restarting the db services on the server (both, although the transactional one is the important one for the Max client -- we use Max 3.7) and clicking away all the error messages on the client fixes the issue.
Last night, no one was in Max and I had just rebooted the server for some maintenance. I checked if Max worked on the server by opening a Max client and it did work just fine.
I then logged into a client computer and attempted to open its Max client. It failed. I checked on the server and it was that same terrible issue -- the server's client also failed.
I restarted the db and cleared the error message warning windows and tried again on the server and it worked. Did the same on the client PC an it also worked.
SO I have a situation where NOTHING else on our network could've caused this.
I can, and will here, provide the log info for that day from both machines and will provide the settings for each as well.

Server:
Log:
02-10-2010 16:30:26 NTMKDE 000004C8 NTDBSMGR.EXE MAX W Resources allocated
02-11-2010 19:26:34 NTMKDE 000004C8 NTDBSMGR.EXE MAX I Resources released
02-11-2010 21:48:01 NTMKDE 000005B4 NTDBSMGR.EXE MAX W Resources allocated
02-11-2010 21:52:25 ECAS_API 00000E94 SYSMAN.EXE MAX E ECASAPI (1.12.1.4083): Error 8505 - An initialization error occurred when trying to establish a session with the Workgroup engine
02-11-2010 21:52:25 ECAS_API 00000E94 SYSMAN.EXE MAX E ECASAPI (1.1.1.4083): Error 8517 - An error occurred when closing the session with the Workgroup engine
02-11-2010 21:52:31 ECAS_API 00000E94 SYSMAN.EXE MAX E ECASAPI (1.12.1.4083): Error 8505 - An initialization error occurred when trying to establish a session with the Workgroup engine
02-11-2010 21:52:31 ECAS_API 00000E94 SYSMAN.EXE MAX E ECASAPI (1.1.1.4083): Error 8517 - An error occurred when closing the session with the Workgroup engine
02-11-2010 21:52:31 ECAS_API 00000E94 SYSMAN.EXE MAX E ECASAPI (1.12.1.4083): Error 8505 - An initialization error occurred when trying to establish a session with the Workgroup engine
02-11-2010 21:52:31 ECAS_API 00000E94 SYSMAN.EXE MAX E ECASAPI (1.1.1.4083): Error 8517 - An error occurred when closing the session with the Workgroup engine
02-11-2010 21:52:51 ECAS_API 00000EB0 pcc.exe MAX E ECASAPI (1.12.1.4083): Error 8505 - An initialization error occurred when trying to establish a session with the Workgroup engine
02-11-2010 21:52:51 ECAS_API 00000EB0 pcc.exe MAX E ECASAPI (1.1.1.4083): Error 8517 - An error occurred when closing the session with the Workgroup engine
02-11-2010 21:54:16 ECAS_API 00000EB0 pcc.exe MAX E ECASAPI (1.12.1.4083): Error 8505 - An initialization error occurred when trying to establish a session with the Workgroup engine
02-11-2010 21:54:16 ECAS_API 00000EB0 pcc.exe MAX E ECASAPI (1.12.1.4083): Error 8505 - An initialization error occurred when trying to establish a session with the Workgroup engine
02-11-2010 21:54:16 ECAS_API 00000EB0 pcc.exe MAX E ECASAPI (1.1.1.4083): Error 8517 - An error occurred when closing the session with the Workgroup engine
02-11-2010 21:54:16 ECAS_API 00000EB0 pcc.exe MAX E ECASAPI (1.1.1.4083): Error 8517 - An error occurred when closing the session with the Workgroup engine
02-11-2010 21:55:23 NTMKDE 000004AC NTDBSMGR.EXE MAX W Resources allocated

I included some extra lines up top, but the relevant issue was in the 21: hour.

Settings:
Server:
Access:
Accept Remote Request: On
Allow Cache Engine Connections: On
Allow Client-stored Credentials: On
Prompt for Client Credentials: Off
Wire Encryption: If Needed
Wire Encryption Level: Medium
Communication buffer size:
Communication Buffer Size: 65153 bytes
MKDE Communication Buffer Size: 65153 bytes
Read Buffer Size: 4096 bytes
Communication protocols:
Auto Reconnect Timeout: 180 sec
Enable Auto Reconnect: Off
Listen IP Address: 192.168.100.154
Supported Protocols: Microsoft TCP/IP
TCP/IP Multihomed: Off
TCP/IP Port: 1583
Compatibility:
Create File Version: 8.x
System Data: If needed
Data integrity:
Archival Logging Selected Files: Off
Initiation Time Limit: 10000 msec
Operation Bundle Limit: 65535
Transaction Durability: Off
Transaction Logging: On
Wait Lock Timeout: 15 sec
Debugging:
Number of Bytes from Data Buffer: 128
Number of Bytes from Key Buffer: 128
Select Operations: All
Trace File Location: C:\PVSW\BIN\MKDE.TRA
Trace Operation: Off
Directories:
DBNames Configuration Location: C:\WINNT
Transaction Log Directory: C:\PVSW\BIN\MKDE\LOG
Working Directory: (blank)
Memory usage:
Allocate Resources at Startup: Off
Back to Minimal State if Inactive: Off
Minimal State Delay: 300 sec
Sort Buffer Size: 0 bytes
System Cache: Off
Performance tuning:
Cache Allocation Size: 429469696 bytes
Communication Threads: 16
File Growth Factor: 15
Index Balancing: Off
Log Buffer Size: 1048576 bytes
Max MicroKernel Memory Usage: 60
Number of Input/Output Threads: 32
Transaction Log Size: 2097152

Client:
Access:
Gateway Durability: Off
Number of Load Retries: 5
Target Engine: Try Server, then Workgroup
Use IDS: Off
Use Local MicroKernel Engine: On
Use Remote MicroKernel Engine: On
Wire Encryption: If Needed
Wire Encryption Level: Medium
Communication protocols:
Connection Timeout: 15 sec
Enable Auto Reconnect: Off
Supported Protocols: Microsoft TCP/IP
Performance tuning:
Compress IDS Data: Off
Use Cache Engine: Off
Security:
IDS Password: <None>
IDS Username: <None>
Runtime Server Support: Yes
Application characteristics:
Embedded Spaces: Off
Splash Screen: On
Verify Key Length: On

Client-16 bit:
Access:
Use Local MicroKernel Engine: On
Use Remote MicroKernel Engine: On
Application characteristics:
Splash Screen: On
Use IDS: Off
Use Thunk: On
Verify Key Length: On
Communication protocols:
Supported rotocols: Microsoft SPXII, Microsoft TCP/IP, NWIPX/SPX SPX
TCP/IP Timeout for Communication Requester: 15 sec
Security:
Runtime Server Support: Yes

This server is an HP DL380 G3 running Windows 2000 with 2 Xeon 2.80GHz CPUs showing as 4 in the OS (HyperThreading?) and 4GB of RAM is detected by the OS (despite 6GB being installed, the OS is maxed out).
I'm open to suggestions on any Pervasive server changes to better use this system's power/RAM, etc.

Client PC is a Windows XP SP3 system with the following info:
Log:
02-04-2010 09:24:27 W3NSL244 00000730 crw32.exe DEPLOY E 3131: Reconnect not attempted, AutoReconnect not enabled on either client or server.
02-11-2010 21:51:16 W3NSL244 00000890 Sysman.exe DEPLOY E 3112: Status 10054 returned while receiving a maximum of 40960 bytes.

I also included an extra line. The 11th is the relevant one, but that's all the log shows.

Settings:
Client:
Access:
Gateway Durability: Off
Number of Load Retries: 5
Target Engine: Server only
Use IDS: Off
Use Local MicroKernel Engine: Off
Use Remote MicroKernel Engine: On
Wire Encryption: If Needed
Wire Encryption Level: Medium
Communication protocols:
Connection Timeout: 15 sec
Enable Auto Reconnect: Off
Supported Protocols: Microsoft TCP/IP
Performance tuning:
Compress IDS Data: Off
Use Cache Engine: Off
Security:
IDS Password: <None>
IDS Username: <None>
Runtime Server Support: Yes
Application characteristics:
Embedded Spaces: Off
Splash Screen: On
Verify Key Length: On

Client-16 bit:
Access:
Use Local MicroKernel Engine: On
Use Remote MicroKernel Engine: On
Application characteristics:
Splash Screen: On
Use IDS: Off
Use Thunk: On
Verify Key Length: On
Communication protocols:
Supported rotocols: Microsoft SPXII, Microsoft TCP/IP, NWIPX/SPX SPX
TCP/IP Timeout for Communication Requester: 15 sec
Security:
Runtime Server Support: Yes


Please help me! I don't know why this keeps happening but the above 2 systems were the only 2 on during the repeat of the issue. And yes, sometimes we come in on a fateful day to the server needed a Pervasive restart despite it being fine the previous day. The server does run MRP at night, so we figured that was the issue, and if that happens, it often is (MRP gets stuck and an error is thrown). Obviously MRP being a Max application uses the server's client settings to communicate.
 
I don't see anything in either the log or the settings that would cause the crashes you describe.
PSQL V8.7 is very old (went unsupported in December 2006) and there are no newer patches beyond 8.7.

At this point, I would suggest trying PSQL v10. It's the current version and is fully supported. I don't know if it'll solve the crashes but if the crashes continue, you can contact Pervasive to find out what might be causing them.

Usually when only one or two systems are involved in a crash like this and there's nothing of significance in the PVSW.LOG, hardware becomes my primary suspect.


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top