We've got an ongoing issue where php 5.2.6 will quit connecting to Oracle 10.2.0.4.0. We can go weeks without any issues and then (usually Saturday mornings) php will no longer be able to connect. The database is up and running and we can connect to it manually with varous DB tools but php won't ever connect again until we reboot the web server. The web server is running IIS 6.0.
We connect using $connection = oci_connect ($userID, $password, $TNS) where $TNS is the appropriare TNS in the local tnsnames.ora file. We go through a connection manager at our data center but I don't know the details on how that works.
One of the reasons this has been dogging us is that we're not really sure who is causing the problem and the various logs haven't shed any light on that. Is it a php issue as it would appear or is the DB itself for some reason rejecting the connections, or is it perhaps the connection manager? Some input in figuring that out would help a lot. Our load is lighter on weekends so that should be the issue. We haven't been able to find any outside processes that could be initiating the problem.
Not really a "root cause" solution, but if you're not using FastCGI, a switch to FastCGI might help with this issue. A PHP process in FastCGI does not live for "weeks". Since the oracle client is loaded dynamically into the PHP process, the automatic process restarts you get with FastCGI should be identical to a web server restart. You can always tweak the FastCGI settings to restart the process more or less often.
If you're using ISAPI, that probably is your root cause though. PHP and ISAPI are bad news when combined. Problems are almost inevitable.
Related
Good morning to everybody, I would like to ask about a problem I have and which I'm not able to solve it.
I have two servers, one is the web server (it contains a large web application) and the other one is the BD server.
The problem is that both are virtualized in a physical server with VMWare and they were running correctly until two weeks ago. In the start of this month we noticed that the web application ran very slow and we started to investigate what was the problem. We have tried a lot of things and we do not know what is the problem and, of course, how to solve it.
Both servers has an internal IP and only web server is accessible from Internet. Only web server access to BD server in order to get the results of queries. It's true that web server and BD server has an older versions of PHP and MySQL respectively.
We did the following tests:
Analyze the consumption of both servers. They are in 1% of memory, swap and al types of consumptions. Our physicial server is new from a year ago and both virtual servers does not use more than 5% of their resources.
Reboot both servers
Reboot physical server (VMWare server)
Restore a backup from 1 and 2 months ago of both servers to discard code and BD data errors
Review code (we do not touch code from before the error)
We did some queries from terminal's webserver and they were fast. We looked for the BD log and we could see that queries have been doing one by one in a "slow" velocity (0,5s for query aprox, depending on the query it can be more than a second).
We suspect that PHP is doing something bad, but we do not touch the code and we do not update PHP version or MySQL version. We want to try to update MySQL version in a new virtual machine and migrate all the data there, but we think it will not solve the problem.
The connection between servers is perfect and we think that layer 2 should not be the problem. In the same webserver we have another web application (Moodle) that connects to this BD server too, and it does not have this problem...
What can be the problem? It's very strange this change of behaviour of the web application. We were on holidays on August and we returned and we found this problem.
For more information we use PHP 5.6.40 (webserver) and MySQL Ver 14.14 Distrib 5.1.60, readline 5.1 (BD server). (yes, we know they are old versions but the web application and BD are old too)
I hope someone can help us, we are a little bit lost.
Thanks for your help!
I'd try updating your servers for one, issues like these are commonly caused by older software.
I'd also start logging or looking into loads so you can determine whatever causes the slow speeds you're getting.
Introduction
For the past couple of days I’ve been messing about with PHP web sockets, in an attempt to retrieve some information in real-time for the user about the various different people connected.
I’m on Ubuntu, running the latest version of XAMPP (located under /opt/lampp/), the web socket I run using PHP which I’ve installed using apt-get install php. This opens a socket with no problem whatsoever.
The problem I’m facing has to do with establishing a connection to the database from the web socket with a little help from PDO. Whenever I attempt to establish the connection to the database located on localhost, I get the following error message:
SQLSTATE[HY000] [2002] No such file or directory
Since PHP and my MySQL server isn’t aware of one another, considering MySQL is run through the instance of XAMPP and the server is run using the version of PHP (which is the same as the one as for XAMPP) I’ve installed using apt-get, one might think that this is the cause of problems. But shouldn’t the server be reachable as long as you have the correct username and password to the server configuration?
Research
I’ve been doing quite some research on the subject, and have found multiple potential solutions for the problem, but neither one appears to do the job. For example, on this question, it is suggested that you can solve this error by doing some witchery to your server software, as well as PHP—I’ve tried this with to apparent success.
On other questions, it’s instead suggested that you change this DSN PDO setup:
$dsn = "mysql:host=$host;port=$port;dbname=$name;charset=$charset";
To instead of using "localhost" for the host, you stick with 127.0.0.1—as a matter of fact, I can’t even connect unto my server if I were to do this. Doing this, my XAMPP gets stuck in some form of endless loop. A minute or so after changing from 127.0.0.1, back to localhost, it starts working again.
I can’t remember where, but I also remember seeing somebody saying it’s not at all doable (connecting to MySQL from a PHP socket), which I’d find extremely strange.
Some people also seem to suggest switching to Node.js for handling real-time connections, but I’d very much like to keep it all PHP if possible.
Furthermore
I’m probably just being a complete moron (I was ;-)), but if anybody can point me in the right direction it would be highly appreciated!
you need to specify the path of the socket
example:
$dsn = 'mysql:dbname=testdb;unix_socket=/path/to/socket';
Try to search the file mysql.sock inside the /opt/lamp
OpenSuse Leap 42.1 (latest upgrade)
Apache2, PHP 5.5 installed
OCI8 installed
ORACLE 11g
Last week, I got some update issues with KDE and did an upgrade of OpenSuse Leap 42.1. I then went over the whole procedure of installing oci8 (as described in http://php.net/manual/en/oci8.installation.php and making sure to use the correct PECL) and everything worked fine.
But when I restarted my system a few hours later, I was't able to connect via hhtp to any vhost due to failed connection to the database.
I get no error logs anywhere, just a white 404 page or the message "Error: Could not connect to database. Aborting." (depending on which page I'm calling). Pages with no connection to the database work perfect!
SQLDeveloper connects without any proble, using the same parameters as in the config-files for the vhosts.
Anyone any idea?
Generally when you get a
ORA-12514
it means that the listenr you are connecting to knows not the servicename/SID you're attempting to connect to. If you get that error it should indicate that the client got some sort of response from the listener which should exclude all sorts of network issues.
This is very much similar to ORA-12514 TNS:listener does not currently know of service requested in connect descriptor
only that the issue sprouted up after an update.
I would first look in the client side tnsnames.ora and the server side listener.ora to check that everything is ok. Also check that the database is registered on the listener. Possibly also check that the db is remotely reachable from a known good client to exclude any issues on the listener configuration.
problem(s) solved!
as there were two different of them provoking a problem salad.
first, the update somehow managed to change some parameters in my config files, first of all the database name.
then, apache update from 2.2 to 2.4 DID change some things in the vhosts config files and therefore the errors were never logged in the former x_error.log and the 404 message was shown.
thx a lot for your response, louigi600!
In our PHP application, we use some Access databases for compatibility with our desktop application. We connect using odbc_connect and DRIVER=Microsoft Access Driver (*.mdb);DBQ=$filename;. This works as expected with most customers...
Some customers experience problems, apparently an error message about a connection limit of 25 connections is thrown and no more connection is possible until the Apache is restarted. Sadly, I have not yet gotten an exact error message, but maybe someone knows this problem already and can enlighten me.
In some cases, it obviously worked to run Apache in CGI mode as the connections get closed after the script finished. But some customers even experience problems in CGI mode.
Is there any way to increase the number of connections or to quickly close the connection? The wierd thing is that I tried to force the problem to appear on my PC, but even with hundreds of concurrent connections I did not have a single error, and the connections seem to close after the script finishes as the .ldb file disappears again.
Maximum connections is set on the webserver in the php.ini with the "MAX USER_CONNECTIONS". When running on localhost, this is rarely a problem. I hade this problem only a few days ago actually when using PDO and MySQL. It worked on localhost, but when I transfered it to a webhosting company it did not work. I solved it by setting persistance to TRUE in the database connection (Means that connections are kept in memory instead of making new connections at each call) If you want more info about this: http://www.php.net/manual/en/features.persistent-connections.php
I would therefore recommend trying ODBC pconnect: http://www.php.net/manual/en/function.odbc-pconnect.php
I have very strange problem with my application, upon occasions I get following error when connecting to postgres. This happens without any pattern, often happens when I run some extensive selenium tests.
Warning: pg_connect() [function.pg-connect]: Unable to connect to PostgreSQL server: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
Postgres logs shows no abnormalities, also other applications that run on same postgres instance have no problems at all.
My Postgres is 8.2.9, running on windows 2008 server
Any hints ?
"server closed the connection unexpectedly" most of the time means the backend crashed. If that's the case there should be some lines about it in the server log.
And by the way the latest version in the 8.2 branch is 8.2.12. Upgrade, test, report.
A random guess. Do you use persistent connections?
You're only showing the client error. Since it means that something happened on the backend, you will need to look in your server logs for information about what actually happened. (The postgres logs and/or the eventlog - check both)
A typical reason for these things to happen is if you are running some antivirus software on the server. If you do, try uninstalling it (not just disabling it) and see if the problem goes away.