Error Sometimes, write to database failed.

[AbdelBorowsky]

Hi !

First, sorry for my english, i hope you understand what I'm going to tell you !

I have an application which sometimes, at differents hours of the day, didn't answer to the write order of users. The navigation into pages of the application is ok, but it's only when we want to validate a page, and so write data in database.
My application uses 7 databases connected together. I think that it's only one database that has the problem. Cause I can write data from screen of my application that don't write in the database which causes problems.

When I look into log of appserver it looks like appserver restarts alone. I have :
Shutdown request received. (5465)
Shutdown request received. (5465)
Shutdown request received. (5465)
Application Server Shutdown. (5476)
Application Server Shutdown. (5476)
Application Server Shutdown. (5476)
Logging level set to = 2
Log entry types activated: ASPlumbing,DB.Connects
Starting application server for apwebrmiweb. (5560)
Application Server Startup. (5473)

And after 30 minutes or sometimes 1 hour, the application works again... Without know why...

Do you have idea about these errors ?

Thanks for your reply.

 

[Cringer]

What version of Progress are you running? Are you aware that with Type II storage areas (v10) and multi-tenancy (v11) the need for multiple databases is reduced? I'm not saying this will solve your problem necessarily, but it might well help to make things a lot more simple as you will not need to manage the commits in the same way.

 

[RealHeavyDude]

I don't see any errors. Have a look into the following KB article http://knowledgebase.progress.com/articles/Article/000028310 which explains the auto trim feature of the agents. I suspect that the messages you see in the log file ( of the AppServer agents ) are coming from agents automatically being shut down by the AppServer broker when they are idle and then being started again when requests are coming in.

What do the log files of the databases say?

Heavy Regards, RealHeavyDude.

 

[AbdelBorowsky]

Thanks for your answers

@Cringer : Version of Porgress is 10.1C. I note what you say

@RealHeavyDude : Thanks. I have already see this KB. That is strange is these messages appears only when the problem happens. That's why I thought it wasn't ordinary.
And there is nothing in log file of the database.

Next time it happens, I will try to update data with a query via AppBuilder and I will see if it takes a long time or not

 

[Cringer]

Any reason why you're not on at least 10.2B? You shouldn't have any issues doing that upgrade and it is a more up to date version of Progress and has had a lot of bug fixes and so on. There's also a good number of extra fixes on that version (8 I think). All in all this should wipe out a good number of known bugs, and improve your experience.

 

[cj_brandt]

look in $DLC/properties/ubroker.properties for the settings for the SrvrInstance. It seems like some app server agents are being trimmed.

initialSrvrInstance: 5
maxSrvrInstance: 5
minSrvrInstance: 5

 

[AbdelBorowsky]

@Cringer : Reason that we are not on 10.2B is that it's not us which manage Progress licence but our software editor... I don't know if it's a good reason but...

@cj_brandt : Thanks for your reply. My settings are :
initialSrvrInstance: 5
maxSrvrInstance: 50
minSrvrInstance: 5

Do you think I have to increase maxSrvrInstance parameter ?

 

[Cringer]

I would be bashing away at my vendor to get me on to 10.2B08 if I were you. The upgrade is easy. There should be 0 impact for it.

 

[Chris Hughes]

Look in your database lg files.

This can happen if you do not have largefilesenabled and you have hit a 2GB limit.

Run

proutil (db name) -C describe against your db's and see whether option 5 is present.

cheers.

 

[AbdelBorowsky]

Thanks for your answer @Chris Hughes . When I run the proutil command I have this result :

OpenEdge Database Description

Database Name : XXX
Version : 150.0
Block Size : 4096
Largest Cluster : 512
Create Date : Wed Jul 8 16:00:13 2009
Last Open Date : Wed Apr 23 20:45:17 2014
Prior Open Date : Wed Apr 23 20:45:17 2014
Schema Change Date : Wed May 22 15:38:40 2013

Before Imaging information
Block Size : 8192
Cluster Size (16K Units) : 32
Last Open Date : Wed Apr 23 20:45:18 2014

Backup Information
Last Full Backup Date : Thu Apr 24 12:47:12 2014
Last Incremental Backup : *** Not yet performed ***

Database Features

ID Feature Active Details
---- --------------------------------- ------ -------
9 64 Bit DBKEYS Yes


What do you mean "option 5" ?

 

[Cringer]

This is what he means...

Database Features

ID Feature Active Details
---- --------------------------------- ------ -------
5 Large Files Yes
9 64 Bit DBKEYS Yes
10 Large Keys Yes
11 64 Bit Sequences Yes

 

[AbdelBorowsky]

Ok thanks. Option not enables for my database.
Limit of 2GB is about files of database ? I have 5 files for this database (5 .d1), but none of them hit the 2GB limit. The most is about 1 GB.

 

[Cringer]

That's it. In your database directory you should have a <db>.st file which will tell you the configuration of the areas. If the files are all < 2GB now then this is unlikely to be the problem you experience.

 

[Rob Fitzpatrick]

If the files are all < 2GB now then this is unlikely to be the problem you experience.

Without large file support enabled, all of his extents have to be less than 2 GB in size.

 

[Chris Hughes]

Post us a copy of your .st files from your DB directory

 

[AbdelBorowsky]

This is my .st file :

#
b /beforeimage_directory/xxxx.b1
#
d "Schema Area":6,32;1 /database_directory/xxxx.d1
#
d "empty tables":7,32;1 /database_directory/xxxx_7.d1
#
d "tables":8,128;512 /database_directory/xxxx_8.d1
#
d "big tables":9,128;512 /database_directory/xxxx_9.d1
#
d "index":10,32;512 /database_directory/xxxx_10.d1

 

[Chris Hughes]

Ok, if you say all the extents are less than 1GB this is not your problem - but if will be a problem in the future if you do not enable large files - BTW your before image file is included in this check!

lg files are limited by size as well. Have you set you app server to not appending to its log file?

certain lg files can be 2 or 4GB max - hopefully one of the other guys on here might chip in.