[DM] I thought that oracle listener is not consuming that many resources. At any rate, ocf:heartbeat:oralsnr doesn't support single listener for multiple instances. Do you have an idea how to do that? How to deal with the tnsping then? Maybe you're better off with the system start script in this case.
[JM] According to the dba, it could lead some memory issue when the listener serves many instances at the same time (in my experience, I have never faced this issue). Let's take a case when the listener is serving multiple instance, and one of the instance fails => ocf:heartbeat:oracle will relocate it to another node, the listener should follow (especially, when we use collocation constraint between RA oracle and oralsnr) this will have a bad impact on the rest of instances. One of the option is to have two listeners (one per node) and configured outside the cluster to host the all instance. But, I keep looking for a better solution. [DM] Hmm, what should then the RA do? Skip the instance and report it started? I'm not sure I follow. [JM] The DBA use a flag Y/N to tell if this instance should run or no. It could be better, for RA to use this flag too: when it's Y start the instance and when It's N, the RA should not start the instance and suitable message in log will be usefull to describe the situation. Now, the challenge is how to monitor this flag. One of the issue that I faced when the DBA when to shutdown the listener and the instance (for launch the cold backup) but, the RA keep pushing them ON. -- Note the dba team usually don't have an access to pcs to disable the resource during this type of operation. I wish my reply could make sense... Thanks, Jihed MSELMI On Sat, Feb 25, 2017 at 8:31 PM Dejan Muhamedagic <[email protected]> wrote: > Hi, > > On Fri, Feb 24, 2017 at 10:09:28AM +0000, Jihed M'selmi wrote: > > Hi, > > > > Using one instance per service leads to a memory issues espacially when > we > > have many instance per node. > > Complain to oracle? ;-> > > I thought that oracle listener is not consuming that many > resources. At any rate, ocf:heartbeat:oralsnr doesn't support > single listener for multiple instances. Do you have an idea how > to do that? How to deal with the tnsping then? Maybe you're > better off with the system start script in this case. > > > Regarding the 2nd point, I think it's better to read the flag on Y/N in > the > > oratab. > > I see some issue/missbehavior, when, some db has N in oratab (the > instance > > shouldn't run), the cluster try to bring it UP. Any thoughts ? > > Hmm, what should then the RA do? Skip the instance and report it > started? I'm not sure I follow. > > Thanks, > > Dejan > > > Cheers, > > > > On Thu, Feb 23, 2017, 5:01 PM emmanuel segura <[email protected]> > wrote: > > > > > I think no, in /usr/lib/ocf/resource.d/heartbeat/oralsnr > > > > > > start function, oralsnr_start = "output=`echo lsnrctl start $listener > > > | runasdba`" > > > stop function, oralsnr_stop = "output=`echo lsnrctl stop $listener | > > > runasdba`" > > > > > > Where listener variable is the resource agent parameter given by > > > pacemaker : # OCF_RESKEY_listener (optional; defaults to LISTENER) > > > > > > Why don't use one listener per instance? > > > > > > 2017-02-23 16:37 GMT+01:00 Jihed M'selmi <[email protected]>: > > > > I was reading the oralsnr script, I found that to stop a listener the > > > agent > > > > uses the lsnrctl to stop the instances. > > > > > > > > My questions, how to configure this agent for an oracle listener > > > attached > > > > the multiple instance ? > > > > > > > > My 2nd quest, is it possible to enhance the ora-common.sh and > > > > resource.d/oracle to take in account the flag y/n in the oratab in > order > > > to > > > > start the database or no ? > > > > > > > > Cheers, > > > > > > > > -- > > > > > > > > > > > > Jihed MSELMI > > > > RHCE, RHCSA, VCP4 > > > > 10 Villa Stendhal, 75020 Paris France > > > > Mobile: +33 (0) 753768653 <+33%207%2053%2076%2086%2053> > > > > > > > > _______________________________________________ > > > > Users mailing list: [email protected] > > > > http://lists.clusterlabs.org/mailman/listinfo/users > > > > > > > > Project Home: http://www.clusterlabs.org > > > > Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > > > Bugs: http://bugs.clusterlabs.org > > > > > > > > > > > > > > > > -- > > > .~. > > > /V\ > > > // \\ > > > /( )\ > > > ^`~'^ > > > > > > _______________________________________________ > > > Users mailing list: [email protected] > > > http://lists.clusterlabs.org/mailman/listinfo/users > > > > > > Project Home: http://www.clusterlabs.org > > > Getting started: > http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > > Bugs: http://bugs.clusterlabs.org > > > > > -- > > > > > > Jihed MSELMI > > RHCE, RHCSA, VCP4 > > 10 Villa Stendhal, 75020 Paris France > > Mobile: +33 (0) 753768653 <+33%207%2053%2076%2086%2053> > > > _______________________________________________ > > Users mailing list: [email protected] > > http://lists.clusterlabs.org/mailman/listinfo/users > > > > Project Home: http://www.clusterlabs.org > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > Bugs: http://bugs.clusterlabs.org > > > _______________________________________________ > Users mailing list: [email protected] > http://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > -- Jihed MSELMI RHCE, RHCSA, VCP4 10 Villa Stendhal, 75020 Paris France Mobile: +33 (0) 753768653
_______________________________________________ Users mailing list: [email protected] http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
