How can I verify if my connection to the database is active? I make the connection but I want to know at a certain moment if the connection is active. In SQL server I can do sqlexec(lnHandle, "select ##version"), but I need it in Advantage Dataserver 11 with VFP.
If I want to know if my connection is active, I consult in the following way:
SELECT Now() FROM System.IOTA
return datetime.
Related
Currently, master-slave replication is finished, and select and insert are branched using the readwritesplit function of maxscale.
I was using common dbcp and checking the connection using the options of testOnBorrow and validationQuery through datasource configuration, but because the query is transmitted through maxscale, select 1 of validationQuery is only transmitted to the slave, and the connection validity of the master cannot be checked.
The master does not check the validity of the connection, so if you connect after not using WAS for a long time, a db connection related error occurs.
to solve this problem
I used master_accept_reads = true,
but I don't want to use it as it will generate more traffic to the master.
As another option persistpoolmax,persistmaxtime
I used, but I got the same error message.
I am wondering if there is a way to send a connection validation query such as ValidationQuery in maxscale or mariadb without distinction between master and slave.
Thank you for reading the long text.
You can use the hint filter to route queries to the master.
https://mariadb.com/kb/en/mariadb-maxscale-24-hintfilter/
I`m in the development stage of an app and I don't make many server\cloud sql calls but for some reason I have an average of 400 usage hours a month.
When I look at the cloud sql active connections dashboard I see there is always at least one active connection but in the read\write operations it's usually on 0 besides the occasional small bumps.
I create a new connection each time I make a request to the server\cloud sql and close the connection each time when I return the response.
the connection code is(I followed the guestbook tutorial\example)
Class.forName("com.mysql.jdbc.GoogleDriver");
this.dbUrl = "jdbc:google:mysql://trivia9991:triviadb?user=root";
this.dbConn = DriverManager.getConnection(dbUrl);
the closing connection code is
this.dbConn.close();
How can this keep a connection open at all time?
If the connection close code is actually running this should not be the issue. You should make sure that the connection is closed even if an exception occurs before hand.
It is also possible that a connection you made using the MySQL command line client is still open.
You can examine what connections are open by connecting using the MySQL command line client and running a SHOW PROCESSLIST; statement.
During development I found that database have large number of lived connections by:
SELECT username, COUNT(*) FROM v$session GROUP BY username;
In order to find who actually hold connection I want to get a list of IP addresses.
During general web search and reading official docs I build query:
SELECT username, seconds_in_wait, machine, port, terminal, program, module, service_name
FROM v$session
WHERE type = 'USER';
where machine is most important part of select. But unfortunately machine field shows host name known by client OS.
Internet full of recommendation to use UTL_INADDR.GET_HOST_ADDRESS which is not applicable in my case. Firstly because of ORA-24247: network access denied by access control list (ACL) and secondly because client OS host name usually defined in /etc/hostname and doesn't available to DNS server in our intranet...
Any other way to retrieve IP of open session to Oracle DB (DB instance hold information about its sockets in any case...).
UPDATE
I under trusted intranet but with unknown network hierarchy.
And I try to find which applications use my tables (several app-servers, I don't know all of them). Some of them overuse connections and need to be fixed. But firstly they should be identified...
Bear in mind that the Oracle session doesn't need to know, and certainly doesn't need to trust, the client name/IP address you're coming from; it's sitting above the network transport layer, and doesn't really care if you're connected over TCP/IP or something else. (I'm not even sure if the listener has to pass the info across, or if it effectively passes a ready-made socket). As you've seen the machine is just what the client declared, like program and other fields in the v$session view; it may not bear any resemblance to anything that DNS or your server's /etc/hosts can resolve, particularly if the client is a Windows box.
What you could do is, at Unix/Linux level (since you refer to /etc/hosts, I assume you aren't on Windows), look for the port and see what address that shows; for example v$session shows my port as 50527, so if I do netstat -an | grep 50527 I see:
tcp 0 0 192.168.1.1:1521 192.168.1.23:50527 ESTABLISHED
So I can see I'm connected from 192.168.1.23. You can do that with a host command if you're running SQL*Plus on the server, but it's still a bit inconvenient. If you needed to do this regularly, and adding a logon trigger to capture it to an audit table isn't an option, and you really had to do it from within the database you could probably write a Java stored procedure to do the lookup from that port for you. But it's probably easier to write a shell script to query the port numbers from v$session and do the lookup that way round.
Thanks to all for digging into my question (which is still general purpose, not exactly mine!!).
Just short answer: you can't get real IP from Oracle system tables.
For this tasks you can use general purpose utilities like netstat or lsof -p <pid-of-oracle> but only on server side!
Some help can come from v$session.port values...
One good suggestion from helpers - use good names from DB clients. They are populated to v$session table rows:
machine, terminal, program, module, service_name
so they can help to identify clients...
The IP address of an incoming connection can usually be found in your Listener log. That is how I track such information when I need to.
I've found my auditing script from 2001 when logon triggers didn't exist AFAIK. It parses the COMMENT$TEXT column of SYS.AUD$ where ACTION#=100 to get the IP address of the client. That column still contains Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=a.a.a.a)(PORT=p)) in our environments.
Try this in your select statements (i.e., from v$session):
utl_inaddr.get_host_address(substr(machine,instr(machine,'\')+1)) ip
Sorry, I don't have the source, but it worked for me.
After rebooting the server, the oracle connection from the Tomcat server times out every night. Prior to the reboot, the connection didn't timeout. Now, in the morning, the application throws a JDBC connection error while accessing the DB. Restarting Tomcat corrects the issue. I'm assuming that's due to the connections being re-established. I think, this is due to the Oracle DB timing out the session. How can the session timeout be disabled in Oracle 11g?
Thanks!
Steve
Config.groovy with dev and test omitted.
dataSource {
pooled = true
}
hibernate {
cache.use_second_level_cache = true
cache.use_query_cache = true
cache.provider_class = 'net.sf.ehcache.hibernate.EhCacheProvider'
}
// environment specific settings
environments {
production {
dataSource {
driverClassName = "oracle.jdbc.driver.OracleDriver"
username = "XXXXX"
password = "XXXXXX"
dialect = "org.hibernate.dialect.Oracle10gDialect"
dbCreate = "update" // one of 'create', 'create-drop','update'
url = "jdbc:oracle:thin:#XXXXXX:1521:xxxx"
}
} }
That's generally controlled by the profile associated with the user Tomcat is connecting as.
SQL> SELECT PROFILE, LIMIT FROM DBA_PROFILES WHERE RESOURCE_NAME = 'IDLE_TIME';
PROFILE LIMIT
------------------------------ ----------------------------------------
DEFAULT UNLIMITED
SQL> SELECT PROFILE FROM DBA_USERS WHERE USERNAME = USER;
PROFILE
------------------------------
DEFAULT
So the user I'm connected to has unlimited idle time - no time out.
Adam has already suggested database profiles.
You could check the SQLNET.ORA file. There's an EXPIRE_TIME parameter but this is for detecting lost connections, rather than terminating existing ones.
Given it happens overnight, it sounds more like an idle timeout, which could be down to a firewall between the app server and database server. Setting the EXPIRE_TIME may stop that happening (as there'll be check every 10 minutes to check the client is alive).
Or possibly the database is being shutdown and restarted and that is killing the connections.
Alternatively, you should be able to configure tomcat with a validationQuery so that it will automatically restart the connection without a tomcat restart
This is likely caused by your application's connection pool; not an Oracle DBMS issue. Most connection pools have a validate statement that can execute before giving you the connection. In oracle you would want "Select 1 from dual".
The reason it started occurring after you restarted the server is that the connection pool was probably added without a restart and you are just now experiencing the use of the connection pool for the first time. What is the modification dates on your resource files that deal with database connections?
Validate Query example:
<Resource name="jdbc/EmployeeDB" auth="Container"
validationQuery="Select 1 from dual" type="javax.sql.DataSource" username="dbusername" password="dbpassword"
driverClassName="org.hsql.jdbcDriver" url="jdbc:HypersonicSQL:database"
maxActive="8" maxIdle="4"/>
EDIT:
In the case of Grails, there are similar configuration options for the grails pool. Example for Grails 1.2 (see release notes for Grails 1.2)
dataSource {
pooled = true
dbCreate = "update"
url = "jdbc:mysql://localhost/yourDB"
driverClassName = "com.mysql.jdbc.Driver"
username = "yourUser"
password = "yourPassword"
properties {
maxActive = 50
maxIdle = 25
minIdle = 5
initialSize = 5
minEvictableIdleTimeMillis = 60000
timeBetweenEvictionRunsMillis = 60000
maxWait = 10000
}
}
I came to this question looking for a way to enable oracle session pool expiration based on total session lifetime instead of idle time.
Another goal is to avoid force closes unexpected to application.
It seems it's possible by setting pool validation query to
select 1 from V$SESSION
where AUDSID = userenv('SESSIONID') and sysdate-LOGON_TIME < 30/24/60
This would close sessions aging over 30 minutes in predictable manner that doesn't affect application.
Does the DB know the connection has dropped, or is the session still listed in v$session? That would indicate, I think, that it's being dropped by the network. Do you know how long it can stay idle before encountering the problem, and if that bears any resemblance to the TCP idle values (net.ipv4.tcp_keepalive_time, tcp_keepalive_probes and tcp_keepalive_interval from sysctl if I recall correctly)? Can't remember whether sysctl changes persist by default, but that might be something that was modified and then reset by the reboot.
Also you might be able to reset your JDBC connections without bouncing the whole server; certainly can in WebLogic, which I realise doesn't help much, but I'm not familiar with the Tomcat equivalents.
Check applications connection Pool settings, rather than altering any session timout settings on the oracle db. It's normal that they time out.
Have a look here:
http://grails.org/doc/1.0.x/guide/3.%20Configuration.html#3.3%20The%20DataSource
Are you sure that you have set the "pooled" parameter correctly?
Greetings,
Lars
EDIT:
Your config seems ok on first glimpse.
I came across this issue today. Maybe it is related to your pain:
"Infinite loop of exceptions if the application is started when the database is down for maintenance"
We are using ADO to access Oracle 10g release 2, Oledb provider for Oracle 10g. We are facing some issue with the connection pooling. The database reside on the remote machine and connection pooling is occuring as it should. But if the remote machine goes down for some reason, the connection is returned from the pool and query on that connection fails. When this connection is closed, it is returned back to the pool instead of being invalid. The subsequent connection opening requests are sucessfull but query fails. This is strange behaviour, according to OLEDB specifications, provider must support DBPROP_CONNECTIONSTATUS property, thus in case of invalid connection, it would not be returned back to the pool.
Things get weired when the remote machine comes up. The connections in the pool are still invalid and although the connection opening succeeds, query on the connection fails. Oracle OLEDB is unable to connect to the server anymore and we have to restart our application. Well this is undesired cause our application is a critical application.
Any ideas on how to get over this.
Thanks
Mubashir
If you are doing this programmatically, use a try block, so that if something does happen, it won't fail. With a try block, you can catch an exception and ignore it, so that the errors are shushed.
You could tell the pool to not accept invalid connections, by marking the connection invalid before it is returned to the pool.
Connections are recovered after 10 minutes by default. Time can be set by the registry key SPTimeout under the oledb provider's root key.
Actually the default connection pool timeout is 120 seconds at least for this Oracle 11 32-bit OLEDB installation. You can find the registry settings at:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Oracle\KEY_orac
Where KEY_orac is the KEY_<oracle_home_name>
The key name is ORAMTS_CONN_POOL_TIMEOUT and the default value is 120.
It does not appear that you can set connection pool parameters at the connection string level.
In most connection pool implementation it is possible to check the connection before using it. For example: you define a check query like select * from dual and if you pick up a connection from the pool this query will be executed. If it fails, then the connection will be excluded from the pool and a new one will be opened.