My problem is that I only have 2 datasources defined... 1 is used to
connect as SYSMAN to the Enterprise Manager where I pick up all the
Instances and there hosts and storage information out of the EM repository.
The other datasource is the connection to OTR's Repository where I use for
the OTR. With this info I'm creating my connection to the target DB's just
to collect the Tablespace and current storage status for my "snapshots".
But I alos use it for the tablespace monitoring which runs about every 5
minutes or in what ever cycle one confiure at setup time. So all my
connections is created on the fly and as soon I have the data I kill the
connection again.

Would be a bit more tricky to create a routine that will edit the
bluedragon.xml and add the proper structure there... But maybe that would
relly be the solution I have to go in the end...  Wan't to get the 2.0
release out ASAP though. So it might have to wait till release 2.0x :)

My temporary workaround for now is to simply ignore the 17002 error if my
target is a RAC Instance since I am more or less 100% sure the my second
connect to the SCAN works just fine.

I will have to bug Matt abitI suppose :)  to get the direction on
programatically editing the bluedragon.xml and be able to create such a
datasource structure.

I generally want to re-do the whole Tablespace monitoring as some kind of
webservice so I'm not having 10+ DBA's or Helpdesk users hitting all
Instances every 5-10 minutes... They should rather just connect to a
service in OTR... That way I'm not hogging the DB's with too much
connections.

/Mats/

PS

Just as info... OTR has moved to a new URL... http://www.project-otr.org.
It's still on the Jelastic Cloud though


On Monday, June 4, 2012, chris schiffman wrote:

> Hi Mats,
>
> In my example, the scan host (prodscan.local) resolves to 3 ips that
> are cycled by the RAC nodes.  The second server is strictly the
> dataguard failover.. So yes, this is using the preferred method of 1
> scan_host, resolving to all rac nodes.  We've extensively tested rac
> failover, dataguard failover, and even scan dns failure.
>
> Another example of the connectstring using the OpenBD api:
>
>     <datasource name="prod_db">
>       <displayname>prod_db</displayname>
>       <password>xxxxxxxxxxx</password>
>       <connectionretries>2</connectionretries>
>       <sqldelete>false</sqldelete>
>       <sqlupdate>false</sqlupdate>
>       <username>myapp</username>
>       <drivername>oracle.jdbc.OracleDriver</drivername>
>       <sqlstoredprocedures>true</sqlstoredprocedures>
>       <perrequestconnections>false</perrequestconnections>
>       <sqlinsert>false</sqlinsert>
>       <sqlselect>false</sqlselect>
>       <connectiontimeout>60</connectiontimeout>
>       <port>1521</port>
>       <server>prodscan.local</server>
>       <databasename>prod_db</databasename>
>       <description></description>
>       <connectstring></connectstring>
>       <logintimeout>60</logintimeout>
>       <initstring></initstring>
>       <hoststring>jdbc:oracle:thin:@prodscan.local:1521/
> myrac_servicename</hoststring>
>       <maxconnections>20</maxconnections>
>       <name>prod_db</name>
>     </datasource>
>
> Where 'prodscan.local' is the SCAN host name.  You'll have to
> manually
> edit the bluedragon.xml file because the admin console doesn't let
> you
> create the hoststring with service_name notation.  Maybe try using
> the
> ojdbc14.jar file and see if the problem persists?
>
>
> Hopefully it'll work for you.
> -chris
>
> --
> online documentation: http://openbd.org/manual/
>  http://groups.google.com/group/openbd?hl=en
>


-- 
*Mats Strömberg*
*NETWORK 23*
*Oracle Tablespace Report (Open Source)*
Project Homepage: www.project-otr.org
Source Code: Google
Code<http://code.google.com/p/oracle-tablespace-report/source/checkout>
Still paying to use CFML? Keep your money and switch to
OpenBD<http://www.openbluedragon.org>

-- 
online documentation: http://openbd.org/manual/
 http://groups.google.com/group/openbd?hl=en

Reply via email to