Database abnormally shutdown

[arisb]

Hi,

This is my first posting message.

We are having a seriuos problem with this database.

OS HPUX 10
PROGRESS V9


scenario:
1) Startup database -OK
2) User can access
3) After sometime the suddently shutdown by itself (like reaching to limitation user access).

We have done:
1) Recreate new structure - OK
2) Restore from backup - OK

When we startup the database - the similar problem happen again.

Today we have found something:
1) Before this rsh (remote shell) can be executed while the database is up
2) But now when we run the rsh during the databse is up, this reported "all ports in used"
3) We only can run rsh when the database is down


This problem was occured for 3 times - 1st day at 8:35am, 2nd day at 8:25am and today at 834am. We suspect this is because there are many users start connecting to database.


We suspect this is due to port problem but we could not very sure where to check.

This happen after we changed the IP address to different segment.



Need your quick feedback.

Appreciated.


Arisb

1st ERROR:
Memory Violation *cant get the exact msg because svr down (Morning 8:00am)

2nd ERROR: (10:30am)
09:39:21 SRV 50: Userid is now ithamhq4d. (708)
09:39:21 SRV 50: Previous message sent on behalf of user 1797. (5512)
09:39:43 SRV 42: Corrupt block detected when attempting to release a buffer.
(4232)
09:39:43 SRV 19: Corrupt block detected when attempting to release a buffer.
(4232)
09:39:43 SRV 42: bmReleaseBuffer: Error occurred in area 6, block number: 794
7142, extent: /sst1a/prodlive/sst1.d1. (10560)
09:39:43 SRV 19: bmReleaseBuffer: Error occurred in area 6, block number: 139
54883, extent: /sst1a/prodlive/sst1.d1. (10560)
09:39:43 SRV 4: Stopped. (2520)
09:39:43 SRV 41: Stopped. (2520)
09:39:43 SRV 32: Stopped. (2520)
09:39:43 SRV 9: Logout by ccwnkhq6t on amiapp2 tp. (453)
09:39:43 SRV 9: Stopped. (2520)
09:39:43 SRV 30: Stopped. (2520)
09:39:43 BROKER 0: Begin ABNORMAL shutdown code 2 (2249)
09:39:43 BROKER 0: Sending signal 7 to pid 25346 for user 1
09:39:43 BROKER 0: Sending signal 7 to pid 25392 for user 2

 

[KnutHandsome]

OS HPUX 10
PROGRESS V9

Need your quick feedback.

There are a couple of people here who may help, but for the quickest and most comprehensive feedback on a possibly difficult/serious issue like this,

1. repost your message on the Peg

dba@peg.com

http://www.peg.com/lists/dba/web/


2. Contact Progress Technical Support

You will also need to supply full patch levels of your OS and Progress version. Hardware info may also be relavent.


The answer may be as simple as upgrading to the latest patch level and repairing through normal Progress utils, but you will get more advice to help you take the right approach at the resources above.

 

[KlausErichsen]

1. repost your message on the Peg
dba@peg.com

You need to pay for that. That may not be a problem, but it
- take time
- it's not nice to say at audience A "go to audience B, they are able to help you"

 

[KlausErichsen]

We had a similar problem with V9, AIX.
The reason was a seldom error related to Private Buffers on self servicing clients (-Bp).

You should call Progress support and collect your logfiles and any coredump.

 

[Casper]

You need to pay for that. That may not be a problem, but it
- take time
- it's not nice to say at audience A "go to audience B, they are able to help you"

1. I think you're still able to ask questions @peg.com without paying...
2. If 1 = true then it's much quicker fur urgents questions then asking here. (you replied Oct 16, question is from Oct 12)
3. Maybe not nice, I don't have an opinion about that, but it sometimes is the best answer to give. You can ask many questions here, but if you need a quick answer then it's still better to ask them @peg as well. This forum has lots less activity (most times) then the peg has.

Anyhow, that doesn't mean I don't like or value this forum. I'm around here a lot (as is KnutHandSome).

Regards,

Casper.

 

[KnutHandsome]

You need to pay for that. That may not be a problem, but it
- take time
- it's not nice to say at audience A "go to audience B, they are able to help you"

It's a fair point, and something that has troubled me in the past, but it is a fact that the Peg has more activity, and greater in depth knowledge, particularly in the DBA area (although normal development questions are handled pretty well here).

Most programmers never use either of these forums, and if you google on 'progress forum', ProgressTalk comes up first - so Peg may not be on the radar for someone unfamiliar with where to get Progress technical advice from.

So the dilemma is:

I know from experience of participating in this forum and the Peg, that the question asked is much more likely to be resolved on the other forum, so do I:

1. Point the poster to alternative resources which they may not be aware of, knowing that this may cause a little irritation to others, but may help the poster resolve their problem.

2. Leave the poster, who seems to be in urgent need of help, to wait for a reply that is probably not going to come, but 'stay on side'.

I prefer to avoid the 'us vs. them' approach, because I find it childish and corrosive in the small Progress world, so I try to help in the only way I can at that point.

A final couple of points on your criticism, and implications of 'disloyalty':

1. I support this forum (and the Peg) financially, do you?

2. I have participated reasonably regularly in both forums (under this and other handles), occasionally, I hope, being helpful.

3. The answer I gave, as pointed out by Casper (thanks, Casper) was the only one received for a couple of days (as I predicted), and could have helped the OP.

4. Progress Tech support isn't free either, the Peg is at least cheap for the support offered, and I think you can still post questions without paying (though why on earth should it be free? someone has to pay for it!).

5. Most of the regular ProgressTalkers also participate on the Peg, sometimes under different handles, so your distinction between the two 'audiences' is somewhat academic.

 

[tsspdx]

You didn't say which version 9, but this is a known issue with 9.1C (P5184).

The official workaround until you can upgrade to 9.1D is,

"To workaround the problem increase the "-n" parameter to a value that is higher than the maximum number of expected connections. "

Obviously if your actual connections exceed your licensed connections you need to $$$ more.