(As I always do, the names of the databases and files are not the real ones, but the numbers are).
Yesterday we got a complain for one client. He said that the RMAN backup of the database was running on working hours and that should not be. I looked at the times of the backup along the week and saw that the backup took much longer than expected.
In this blog will try to share some of my experiences on Oracle Database performance and troubleshooting.
jueves, 19 de enero de 2017
miércoles, 18 de enero de 2017
Recovering a deleted datafile using lsof
Here is a little trick that can be useful in case of a accidental delete of one datafile.
I do not recommend or encourage anyone to do it, but could be useful under certain specific situations.
I do not recommend or encourage anyone to do it, but could be useful under certain specific situations.
viernes, 23 de diciembre de 2016
How to find out what is consuming all of my bandwidth
Some days ago we received a complain from the networking department stating that some connections from one of our database servers were consuming most of the available bandwidth.
Obviously, the highest chance was that it was an oracle process, more, because it was our server who was sending the data, and the only applicacion in this server is Oracle.
Obviously, the highest chance was that it was an oracle process, more, because it was our server who was sending the data, and the only applicacion in this server is Oracle.
martes, 29 de noviembre de 2016
Mapping a process in a remote server to a oracle session
Something we have probably needed many times is to find in a remote server the program that is running a session against our database.
Perhaps and for any reason, we need to know exactly which concrete process in the remote server is accessing our database (from the
operating system perspective).
Let's say is a sqlplus prompt, but when we log on the remote system, we see that there are many sqlplus processes runnning. Which
is the right one?
Perhaps and for any reason, we need to know exactly which concrete process in the remote server is accessing our database (from the
operating system perspective).
Let's say is a sqlplus prompt, but when we log on the remote system, we see that there are many sqlplus processes runnning. Which
is the right one?
viernes, 18 de noviembre de 2016
Who And What SQL Is Using Temp Segments ?
Recently I came across an incident related to temporary segments. When I checked the view V$SORT_USAGE to take a look at what was using my temporary tablespace, I got shocked to see a query of the type "select 1 from dual". Obviously, this query does not do any kind of sort!
So I decided to take a close look at the issue.
First thing I noticed:
So I decided to take a close look at the issue.
First thing I noticed:
jueves, 10 de noviembre de 2016
ORA-00030, 00000, "user session ID does not exist"
I think it's worth to write a short entry in my blog regards to it. That happened to me some days ago. First time I met this issue.
We were told that a session was blocking another session and preventing it to run a DELETE on one table. Up to this point, everything is normal. I ran an ALTER SYSTEM KILL SESSION.. on the blocking session, and, to my surprise, appeared this message:
We were told that a session was blocking another session and preventing it to run a DELETE on one table. Up to this point, everything is normal. I ran an ALTER SYSTEM KILL SESSION.. on the blocking session, and, to my surprise, appeared this message:
lunes, 17 de octubre de 2016
AWR Does not show where's the problem. Just shows what is happening!
It looks like something that does not need to be said, but is a trap where many junior DBA fall. AWR (or Statspack) can be misleading if we do
not keep in mind this detail:
What AWR and Statspack report shows is not where or what is the problem, but just what was happenning in the database at the moment of the snapshot!.
That means, that we need to interpret correctly what we are seeing at the report. Here I'd like to share an example that illustrates this point.
What AWR and Statspack report shows is not where or what is the problem, but just what was happenning in the database at the moment of the snapshot!.
That means, that we need to interpret correctly what we are seeing at the report. Here I'd like to share an example that illustrates this point.
Suscribirse a:
Entradas (Atom)