-lruskips

Posted by Gareth Vincent on 13-Nov-2015 03:11

Hi,

Just wondering if anyone has had any problems using the -lruskips param in the conmgr.properties file on 11.5.1. Searching on the KB I see there was a problem prior to 11.4. 

below is the an extract from my conmgr.properties file

[configuration.waterberg_toyota_retaildb.defaultconfiguration]
maxusers=30
maxservers=9
blocksindatabasebuffers=10000
sharedmemorypin=true
servergroups=waterberg_toyota_retaildb.defaultconfiguration.defaultservergroup, waterberg_toyota_retaildb.defaultconfiguration.servergroup-2
beforeimagestall=true
locktableentries=500000
afterimageprocess=false
displayname=defaultConfiguration
monitored=true
spinlockretries=10000
storageobjectsize=2048
asynchronouspagewriters=1
database=waterberg_toyota_retaildb
beforeimageprocess=true
watchdogprocess=true
otherargs=-lruskips 50

although the value of lruskips is set to 50 it appears that it is ignoring this argument and setting itself back to 0.

Any assistance would be appreciated

Gareth

All Replies

Posted by James Palmer on 13-Nov-2015 03:31

Hi Gareth,

We've got this set in otherargs and it's picking it up fine. That's 11.5.1 on Windows 2012 R2. Where do you see it's set to 0? DB Log file? I don't mean this to be patronising. Just checking you're not getting lruskips and lru2skips muddled?

Posted by Gareth Vincent on 13-Nov-2015 03:42

Hi James,

Yes, when looking at the DB log file it is still set to 0.  We are running on Solaris 10.  I'm able to set it through PROMON as well as proserve the DB from command line with -lruskip.  For some reason it is just ignoring the value set in the conmgr.properties file.  I'm not running B2 so I guess that is where the lru2skip comes from.

Posted by Gareth Vincent on 13-Nov-2015 04:00

Its probably worth mentioning we are not starting the DB's with dbman but rather using proserve -servergroup to read in the conmgr.properties file.  With further testing it works if I simply startup the DB with dbman.  I'm not sure if this is a bug when using proserve -servergroup that it ignores "otherargs".  I'm now looking to see if a can can a .pf within the conmgr.properties file to see if that works.

Posted by ChUIMonster on 13-Nov-2015 06:33

A  .pf file would go in otherargs so that won't help if you want it to work with proserve via -servergroup & conmgr.properties.  (And I think that must be a bug -- you should report it.)

I'm curious -- what is the attraction of "proserve -servergroup" vs plain old proserve or dbman?

Posted by Gareth Vincent on 13-Nov-2015 07:15

In a nutshell we were trying to reduce the java footprint on on server and reserve memory.  We started off with dbman so we already had all the params setup accordingly in the conmgr.properties file.  It was just easier to switch over to "proserve -servergroup"I was able to point it to a pf file with the following command:

${PROSERVE} -servergroup ${ENVIRONMENT}_retaildb.defaultconfiguration.defaultservergroup -pf /usr/local/bin/rs/db.pf  &

Posted by ChUIMonster on 13-Nov-2015 07:38

You could do it all with proserve and .pf files -- from a database perspective there is no need at all to do anything at all with conmgr.properties and the admin server and so forth.

If other parts of your application use app servers and such then you would need the admin server.  But those bits use ubroker not conmgr.

Posted by Simon L. Prinsloo on 13-Nov-2015 10:34

Would OEManagement be able to monitor the databases if they are not in the conmgr.properties?

In any case, the server that Gareth refers to hosts the production environments for over 50 customers, each with several databases. Maintaining all the databases in a central location (conmgr.properties) simplifies life a lot over maintaining individual .pf files. It also makes it easy to check a setting across the whole set, because you can simply grep for it.

The problem is that it takes a lot of time to start or stop all databases using dbman. It also spike the machine's need for memory/swap space to absurd levels, yet OEManagement is a convenient, central tool to manage individual customers.

Hence the scripts that perform "bulk" work (e.g. drop or start everything before and after maintenance) do not use dbman, but small scale operations does.

Posted by Libor Laubacher on 13-Nov-2015 10:37

> Would OEManagement be able to monitor the databases if they are not in the conmgr.properties?

Yes, you can add them as "scripted".

Posted by James Palmer on 13-Nov-2015 10:37

Correct. That's one of the problems with using pf''s - you can't see the DB status in OEM.

Posted by James Palmer on 13-Nov-2015 10:38

That's news to me Libor. When was that added?

Posted by ChUIMonster on 13-Nov-2015 10:42

I think it is time to bite my tongue ;)

Posted by Libor Laubacher on 13-Nov-2015 10:46

Since 2.0A version of OEM (Fathom Mgmt at that time).

Posted by James Palmer on 13-Nov-2015 10:49

Wow. That's actually embarrassing. Will have to investigate!!

Posted by James Palmer on 13-Nov-2015 10:49

[quote user="ChUIMonster"]

I think it is time to bite my tongue ;)

[/quote]

I can't imagine what you might be itching to say! 

Posted by Libor Laubacher on 13-Nov-2015 10:55

Maybe I misunderstood the question - but in order for OEM to monitor a database, that database does not have to be under adminserver (eg managed), it can be started by proserve (eg scripted) as well. One just need to start dbagent, which feeds OEM with data/status of that database.

Posted by Tim Kuehn on 13-Nov-2015 11:16

Libor - you're correct - there is a way for the standard script commands to start/stop a db and let the adminserver know what they're doing.It's just a matter of supplying the appropriate command line options.

This thread is closed