V$undostat and maxqueryid

Hi,
Using Oracle 11.1.0.7 one of our customers had space problems with UNDO tablespace. We tried to get an overview of whats going on using v$undostat.
One of the columns is MAXQUERYID and join to v$sqlarea we tried to pinpoint longrunning sql. But even on heavy used production system (or low used testsystems) we always see one statement: select 1 from obj$ where name = 'DBA_QUEUE_SCEDULES'
Anyone knows why we always get this and/or maybe what it is? It is not running slow if tried in sqlplus, so we think we miss a point here!
Best
Jens

MAXQUERYID SQL identifier of the longest running SQL statement in the period
as shown in the following link
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2174.htm#i1422075
but does not identify (necessarily) that this SQL statement uses UNDO.
MAXQUERYID (in combination with MAXQUERYLEN) if anything you need to estimate correctly the UNDO_RETENTION.
To get an idea about undo_retention and sizing of UNDO tablespace try looking here
http://www.oracle.com/technology/oramag/code/tips2004/032904.html
best regards
Donatello Settembrino

Similar Messages

Longest query by the user

Dear all,
10.2.0.4 on solaris 10
Is there any option for a certain period of time, how to know the longest sql executed by a particular user in the
database ?. I tried auditing user, but doesn't reveal the info that I require ?
Any idea ?
Kai

You can try to use V$UNDOSTAT which by default stores data for the last seven days but Oracle cannot guarantee that the SQL statement is still in the shared pool and you cannot get easily the related user account:
select sql_text
from v$undostat u, v$sql s
where maxquerylen = (select max(maxquerylen) from v$undostat)
and u.maxqueryid = s.sql_idEdited by: P. Forstmann on 24 août 2011 13:28

Problem with UNDO tablespace

Hi guys.
Our database has 50GB of undo tablespace. I decided to create a second undo tablespace and switch to the new one. Since doing that yesterday, the size of the old undo is 49GB (was thinking that the values will drop to zero) and the new tablespace keeps increasing in size! Its size now is about 20GB. I do have the following question.
a) If I restart the database, it the value of the old undo going to fall to zero?
b) undo_retention=86400. Setting this value to a lesser value say 800seconds, it is going to act the performance of the database? Is it going to release the space on the old undo?
Thanks and any help is appreciated.
David

The undo tablespace will not automatically shrink size, since you have a new undo tablespace in place. You can drop the old one if you don't plan to use it.
Set lower undo_retention will certainly help to contain the undo space usage. However you should query v$undostat and v$rollstat to estimate the amount of undo space required for the current workload then size the undo tablespace accordingly. Turn off the auto extend on undo tablespace.

Archive log generation

Hai all,
In My production environment, some times archives log are generating 5-6 logs a min.. very less no of users are connected to the database now..
rw-r----- 1 oraprod dba 10484224 Jan 12 14:10 prod_arch_4810.arc
-rw-r----- 1 oraprod dba 10484224 Jan 12 14:10 prod_arch_4811.arc
-rw-r----- 1 oraprod dba 10483712 Jan 12 14:10 prod_arch_4812.arc
-rw-r----- 1 oraprod dba 10484224 Jan 12 14:10 prod_arch_4813.arc
-rw-r----- 1 oraprod dba 10484224 Jan 12 14:10 prod_arch_4814.arc
-rw-r----- 1 oraprod dba 10484224 Jan 12 14:10 prod_arch_4815.arc
Y is this happenin ?
Any comments or ideas to resolve this?
Yusuf

Whenever you create a thread, it is always advisable to specify your current OS and DB versions.
You could be generating this redo information by means of your scheduled tasks or by the current users activity, the few concurrent number of users doesn't mean they won't be generating a lot of transactions. Check your v$undostat and v$rollstat, v$transaction, and v$session to monitor users and transaction activity.
10M for a redo log size IMO is very little for the current transaction requirements for most databases. Your database currently generates transaction information at a rate of about 50M/min. With 100M redolog files you would be generating one archivelog file around each two minutes, instead of the current 5 archivelog per minute.
Since your database is highly transactional, make sure you have enough free space to store your generated archive log files, you will be generating about 3G/hr.
~ Madrid

AUM not re-using expired UNDO extents

Hi there,
The space consumption in the UNDO tablespace is continuesly growing.
I've increased the size of the UNDO tablespace several times now (currently 400M) but this offers no permanent solution (datafiles are set in no autoextent mode).
It's possible to calculate the maximum size that you need for your UNDO tablespace using certain values from v$undostat and v$parameter.
According to this calculation our UNDO tablespace shouldn't be larger than 100M.
It looks like there is a problem with re-using expired UNDO extents, as indicated below (SUM(EXPBLKREUCNT) = 0 ):
SQL> select sum(EXPSTEALCNT), sum(EXPBLKRELCNT), sum(EXPBLKREUCNT) from v$undostat;
SUM(EXPSTEALCNT): 7
SUM(EXPBLKRELCNT): 1792
SUM(EXPBLKREUCNT): 0
Does anyone experience the same problem ?
Regards,
Miklas

what is your undo retention set to

What is occupying my undo ???

Hi,
I see my undo space is almost completely used up (using the below pasted query).
SELECT   d.status, db.NAME dbname, d.tablespace_name tsname,
         d.extent_management, d.allocation_type,
         TO_CHAR (NVL (d.min_extlen / 1024, 0),
                  '99G999G990D90',
                  'NLS_NUMERIC_CHARACTERS = '',.'' '
                 ) "ALLOC_SIZE (K)",
         d.CONTENTS "Type",
         CASE
            WHEN (d.CONTENTS = 'TEMPORARY')
               THEN TO_CHAR (NVL (t.BYTES / 1024 / 1024, 0),
                             '99G999G990D90',
                             'NLS_NUMERIC_CHARACTERS = '',.'' '
            ELSE TO_CHAR (NVL (a.BYTES / 1024 / 1024, 0),
                          '99G999G990D90',
                          'NLS_NUMERIC_CHARACTERS = '',.'' '
         END AS "Size (M)",
         TO_CHAR (NVL ((a.BYTES - NVL (f.BYTES, 0)) / 1024 / 1024, 0),
                  '99G999G990D90',
                  'NLS_NUMERIC_CHARACTERS = '',.'' '
                 ) "Used (M)",
         TO_CHAR (NVL ((a.BYTES - NVL (f.BYTES, 0)) / a.BYTES * 100, 0),
                  '990D90',
                  'NLS_NUMERIC_CHARACTERS = '',.'' '
                 ) "Used (%)"
    FROM SYS.dba_tablespaces d,
         (SELECT   tablespace_name, SUM (BYTES) BYTES
              FROM dba_data_files
          GROUP BY tablespace_name) a,
         (SELECT   tablespace_name, SUM (BYTES) BYTES
              FROM dba_temp_files
          GROUP BY tablespace_name) t,
         (SELECT   tablespace_name, SUM (BYTES) BYTES
              FROM dba_free_space
          GROUP BY tablespace_name) f,
         v$database db
   WHERE d.tablespace_name = a.tablespace_name(+)
     AND d.tablespace_name = f.tablespace_name(+)
     AND d.tablespace_name = t.tablespace_name(+)
ORDER BY 10 DESC;This is noticed when certain weekday jobs run that refresh about 8 materialized views. I see that my undo has about 16 GB. I've summed sizes up all the tables together and found that it does not come any where close to 16 GB.
How do find out what is actually taking up my undo space.
Thanks,
CJM

You can start by checking V$UNDOSTAT and V$TRANSACTION. Join V$TRANSACTION SES_ADDR to V$SESSION SADDR to find out which sessions have active transactions. USED_UBLK or USED_UREC will tell you how much undo each transaction is using.
See: How To Determine Who Is Using Undo Tablespace And How Much? [ID 304513.1] on Oracle Support.
You can try the Undo Advisor if you're trying to size your undo tablespace. Keep in mind that index maintenance will also generate undo, so you can't just consider the size of the tables.
Regards,
Bob

V$UNDOSTAT - contains less than 1008 rows and last DB restart in 12/2007

Hi all,
Our version is single instance Oracle 9.2.0.7.0 on AIX 5.3:
On our productive system (Datawarehouse with heavy data loads) the V$UNDOSTAT view contains not all rows for a 7-days cycle. When I step into the view there are less rows in it
(about 20- 50 or so).
On the other hand in our development system (separate server ,same OS, database) I can find all rows for the week. The only difference :-) seems to be the workload on the two different systems.
Can you give me a clue?
bb
Message was edited by:
berndboecker

Hi Kim,
the last instance start was on Dec. 15th, last year - so it has to contain 1008 rows.
I agree with you: I can think of only for a restart that the cycle starts again.
But this doesn't happen. But for some reason it cleans out the rows.
I can see this occuring several times per day.Let's say I query
Select count(*) from v$undostat
time t1: count(*) 10 " we had already some intervals in it, but not 1008 :-(
time t2 + 10 minutes count(*) 11 " fine
time t3 + 10 minutes count(*) 12 " fine
**** let's wait for an hour
time t9 + 10 minutes count(*) 8 "oops, we lost some rows again
In the Alert log I can see that the database did the usually checkpoints and archives
at that time.
The only implication I can think of is that the undo statistics are not really usefull for calculating a new undo retention time based on the workload in V$UNDOSTAT (you can get accurate values in the 7 days cycle but not with only some rows.

ORA-01555 and v$undostat


Hi,
My application was getting ORA-01555 (this is confirmed in alert.log).
When I query v$undostat for the involved period:

<blockquote>

select UnxpStealCnt, UnxpBlkRelCnt, UnxpBlkReuCnt, ExpStealCnt, ExpBlkRelCnt, ExpBlkReuCnt, NoSpaceErrCnt
from v$undostat where SSoldErrCnt != 0

</blockquote>

I do not understand why all theses columns have a zero value.
I was expecting to have at least 1 in ExpBlkReuCnt or in ExpStealCnt.
How is it possible to have (because I have) ORA-01555 without any value in thoses columns ?
Thanks for your bright explanations,
Leo.

Edited by: Leo Anderson on 24 oct. 2008 10:28

Leo Anderson wrote:
During the "fatal" period, the MaxQueryLen = 6000 and the Tuned_UndoRetention = 6800
All columns UnxpStealCnt, UnxpBlkRelCnt, UnxpBlkReuCnt, ExpStealCnt, ExpBlkRelCnt, ExpBlkReuCnt, NoSpaceErrCnt has zero value
So, I presume increasing undo_retention parameter will have no effect ?
But why no columns has non-zero value ? (in particular ExpBlkReuCnt)
EDIT : The datafile underlying my UNDOTBS is autoextensible, and bytes/maxbytes is about 32% so it could still grow
In this case I would assume that you might suffer from an ORA-01555 due to "delayed block cleanout". This errors occurs if delayed block cleanout is being performed, the transaction slot has been overwritten and some other conditions apply. For a very good explanation under what circumstances this could happen, read MetaLink note 45895.1 (although the note applies to manual rollback segment management the explanation of the "delayed block cleanout" case still applies to automatic undo management, but the solutions mentioned there do not)
You can check if your query generates a lot of redo (and you can make sure that this redo is not generated by some other DML of the same session) then it performs "delayed block cleanout".
The best solution to prevent this from happening is to attempt to generate "clean" blocks right from the start, e.g. by using direct-path inserts (APPEND hint) or Create Table As Select (CTAS). This way you prevent the "delayed block cleanout" from happening.
Other means are performing full table scans on the modified object, e.g. by gathering statistics using DBMS_STATS or explicitly running a query on the object using a full table scan right after large modifications.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

V$UNDOSTAT BEGIN)TIME GREATER THAN SYSDATE

I have 18 rows in V$UNDOSTAT with begin_time greater than sysdate.
what could have caused that?
I noticed this anomaly when i was looking for some undo information.
All that has happened recently is, I have restored the db (9.2.0.1 on REHL 3)
on a different server as the original server had a bad disk (RAID5 rebuild was taking too long). So i shutdown the db and copied all files from the last cold backup to the new server(same config)and restored all the archlogs. Everything has been going fine since than.
Would a db bounce reset the date anoamly??
Any ideas !!!
Thankyou

Hello,
Yes you are right, the MAXQUERYLEN of the query *60mwzy51cs6sx* is very high (213380 seconde = 2,5 day) :
07-21-2010 16:48:2010 213380 60mwzy51cs6sx
07-21-2010 20:07:2010 225213 60mwzy51cs6sxAnd more over, it seems that the same query repeat several time and the MAXQUERYLEN is higher and higher.
You may get the offending query as follow:
Select sql_text from v$sqltext where sql_id = '60mwzy51cs6sx' /* MAXQUERYID value */It seems that the MAXQUERYLEN is never resetted for this query.
If you are sure that this query is not still running for almost 3 days so, I don't know why there's this kind of behaviour and, if I were you, I'll ask to the support.
Best regards,
Jean-Valentin

V$undostat, maxquerylen varies during the intervals

Hi,
Oracle 10.2.0.4 with undo_retention=900 and no guarantee.
I have been staring at this all day. I noticed that our current undo recommendation on one of our production databases was telling us the undo tablespace needs to be 2 times larger (+250GB). I got a little concerned because just last week the recommendation was well below half of that. Looking at v$undostat, I noticed where the problem must be. The maxquerylen is saying that there is a sql statement that ran on 7/19/2010 that v$undostat still, apparently, thinks that the query is active I guess. The job related to the query finished successfully in less than 40 minutes on the day it ran(on 7/19).
So, to be clear... there is no active transaction, even now, that is more than 500 seconds old.
Anybody have any clue as to why/how the maxquerylen would jump up and down as shown below?
TO_CHAR(END_TIME,'MM- MAXQUERYLEN MAXQUERYID
07-21-2010 16:38:2010 1839 9xvq4g6100pdy
07-21-2010 16:48:2010 213380 60mwzy51cs6sx
07-21-2010 16:58:2010 213987 60mwzy51cs6sx
07-21-2010 17:08:2010 164 cbq154rd1rag1
07-21-2010 17:18:2010 770 cbq154rd1rag1
07-21-2010 17:28:2010 215807 60mwzy51cs6sx
07-21-2010 17:38:2010 216414 60mwzy51cs6sx
07-21-2010 17:48:2010 497 cbq154rd1rag1
07-21-2010 17:58:2010 217627 60mwzy51cs6sx
07-21-2010 18:08:2010 218233 60mwzy51cs6sx
07-21-2010 18:18:2010 218842 60mwzy51cs6sx
07-21-2010 18:28:2010 219448 60mwzy51cs6sx
07-21-2010 18:38:2010 220055 60mwzy51cs6sx
07-21-2010 18:48:2010 220662 60mwzy51cs6sx
07-21-2010 18:58:2010 221269 60mwzy51cs6sx
07-21-2010 19:08:2010 221876 60mwzy51cs6sx
07-21-2010 19:18:2010 1003 ck24v2bkkru13
07-21-2010 19:28:2010 1611 ck24v2bkkru13
07-21-2010 19:38:2010 2217 ck24v2bkkru13
07-21-2010 19:48:2010 2824 ck24v2bkkru13
07-21-2010 19:58:2010 416 g9b1yvbnj8qbv
07-21-2010 20:07:2010 225213 60mwzy51cs6sx
Thanks!!

Hello,
Yes you are right, the MAXQUERYLEN of the query *60mwzy51cs6sx* is very high (213380 seconde = 2,5 day) :
07-21-2010 16:48:2010 213380 60mwzy51cs6sx
07-21-2010 20:07:2010 225213 60mwzy51cs6sxAnd more over, it seems that the same query repeat several time and the MAXQUERYLEN is higher and higher.
You may get the offending query as follow:
Select sql_text from v$sqltext where sql_id = '60mwzy51cs6sx' /* MAXQUERYID value */It seems that the MAXQUERYLEN is never resetted for this query.
If you are sure that this query is not still running for almost 3 days so, I don't know why there's this kind of behaviour and, if I were you, I'll ask to the support.
Best regards,
Jean-Valentin

Need help understanding a column in v$undostat

Version: 9.2.0.4.0, Solaris
Undo type: AUTO
Undo size: 600 MB
UNDO_RETENTION = 900 (15 min)
When I do
select * from v$undostat
Column name: NOSPACEERRCNT
The thing I dont understand is that: when I get non-zero rows for that column does it mean that users got error since No Free undo space available?
Issue is NO development users (of DB) complained with any error when the NOSPACEERRCNT had non-zero value?
--- Oracle notes ---
NOSPACEERRCNT (NUMBER)
Identifies the number of times space was requested in the undo tablespace and there was no free space available. That is, all of the space in the undo tablespace was in use by active transactions. The corrective action is to add more space to the undo tablespace.

Can we ignore that no space errors ? The application code should not because this error means involved queries got some ORA-XXXX errors and have been rolled back and normally the application code should have either retried to run the queries or rolled back the corresponding transactions.
What this is ssolderrcnt,nospaceerrcnt columns means ?See the SQL Reference.
Message was edited by:
Pierre Forstmann

Undo Tablespace and Temporary Tablespace - autoextend ?

- In general, should I allow the Undo Tablespace to grow (autoextend)?
- In general, should I allow the Temporary Tablespace to grow (autoextend)?

The size of undo tablespace should always keeps in mind otherwiase you eill get ORA-1555 or out of space errors.
This paper is to help DBA’s in calculating the size of UNDO tablespace by using a simple formula.
It is tough to know about the number of transactions and subsequently number of rows changed per second.
So I suggest having a “big undo tablespace” to start with and based on load, after doing some calculations and resize your UNDO tablespace.
In my case one of the applications was going to production (live), and I had no idea that how many transactions will happen against this database. All what I was told that there will be optimum (transactional) activity on this database.
So I started with UNDO tablespace with size of 3GB and datafiles with autoextend “on” .
Note:
In production, you must be very careful in using this (autoextend on) as the space may grow to inifinity very fast. So my advice is either dont use this option, or use with "maxsize" or continuously monitor space (which is tough).
I month later, I noticed the activity from V$undostat.
Here is the step by step approach:
Step 1: Longest running query.
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
1793
This gives you ideal value for UNDO_RETENTION. To be on the safer size you should add few more seconds to get the right value. So in my case, the size of undo retention should be say 2000 secs.
Step 2: Size of UNDO tablespace.
Size of UNDO needed = UNDO_RETENTION x [UNDO block Generation per sec x DB_BLOCK_SIZE] + Overhead(30xDB_BLOCK_SIZE)
Out of these we know UNDO_RETENTION and DB_BLOCK_SIZE
All we need is to find out “UNDO Blocks per second”
Which can be easily fetched from v$undostat
SQL> SELECT (SUM(undoblks))/ SUM ((end_time - begin_time) * 24*60*60) "UPS"
2 FROM v$undostat;
UPS
8.11985583
V$undostat stores data for every 10 mins and begin/end times are start/end time of those intervals. We multiplied it with 24*60*60 because the difference between two dates will be in days and to get to seconds, we need it to multiply with 24hrs*60mins*60secs
So now we have all the values needed.
Undo size needed = [8.12 x 2000 x 8192] + [30 x 8192] = 133283840 bytes = 127.11 MB

Whisch one is correct for undo_retention and what is the difference

Hi ALL,
whisch one is correct for undo_retention and what is the difference
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
6060
SQL> select max(maxquerylen) from dba_hist_undostat;
MAX(MAXQUERYLEN)
17221

hi Afzal,
you can use begin_time & end_time of v$undostat -> to specify the time interval of your interest.
A brief note, of what you have discussed here:
maxquerylen
Identifies the length of the longest query (in seconds) executed in the instance during the period. You can use this statistic to estimate the proper setting of the UNDO_RETENTION initialization parameter. The length of a query is measured from the cursor open time to the last fetch/execute time of the cursor. Only the length of those cursors that have been fetched/executed during the period are reflected in the view.
V$UNDOSTAT is dynamic, showing current stats.
DBA_HIST_UNDOSTAT displays the history of histograms of statistical data to show how well the system is working. The available statistics include undo space consumption, transaction concurrency, and length of queries executed in the instance.This view contains snapshots of V$UNDOSTAT
hope it help.
regards,
X

A problem with Threads and loops.

Hi, I have some code that needs to be constantly running, like while(true)
      //code here
}However, the code just checks to see if the user has input anything (and then if the user has, it goes to do some other stuff) so I don't need it constantly running and hogging up 98% of the CPU. So I made my class (which has the method that needs to be looped, call it ClassA) implement Runnable. Then I just added the method which needed to be looped into the public void run()
I have another class which creates an instance of the above class (call it ClassB), and the main(String[] args) is in there.
public static void main(String[] args)
          ClassA test = new ClassA();
          Thread thread = new Thread(test.getInstanceOfClassA());
          thread.start();
          while(true)
                       //I do not know what to put here
               try
                    thread.sleep(100);
               catch(InterruptedException iex)
     }However, the thread only calls run() once,(duh...) but I can't think of away to get it to run - sleep - run -sleep forever. Can someone help me?

Hi, I have some code that needs to be constantly
running, like while(true)
//code here
}However, the code just checks to see if the user has
input anything (and then if the user has, it goes to
do some other stuff) so I don't need it constantly
running and hogging up 98% of the CPU. Where does the user input come from. Are you reading from an InputStream? If so, then your loop will be blocked anyway when reading from the InputStream until data is available. During that time, the loop will not consume processor cycles.
public static void main(String[] args)
          ClassA test = new ClassA();
Thread thread = new Thread(test.getInstanceOfClassA());I have never seen this idiom. If ClassA instanceof Runnable, you simply write new Thread(test).
          thread.start();
          while(true)
//I do not know what to put
do not know what to put here
               try
                    thread.sleep(100);
               catch(InterruptedException iex)
     }However, the thread only calls run() once,(duh...)Yeah, why would you want to call it more than once given that you have an infinite loop in ClassA.run()?
Harald.
Java Text Crunching: http://www.ebi.ac.uk/Rebholz-srv/whatizit/software

A problem with Threads and MMapi

I am tring to execute a class based on Game canvas.
The problem begin when I try to Play both a MIDI tone and to run an infinit Thread loop.
The MIDI tone "Stammers".
How to over come the problem?
Thanks in advance
Kobi
See Code example below:
import java.io.IOException;
import java.io.InputStream;
import javax.microedition.lcdui.Graphics;
import javax.microedition.lcdui.Image;
import javax.microedition.lcdui.game.GameCanvas;
import javax.microedition.media.Manager;
import javax.microedition.media.MediaException;
import javax.microedition.media.Player;
public class MainScreenCanvas extends GameCanvas implements Runnable {
 private MainMIDlet parent;
 private boolean mTrucking = false;
 Image imgBackgound = null;
 int imgBackgoundX = 0, imgBackgoundY = 0;
 Player player;
 public MainScreenCanvas(MainMIDlet parent)
 super(true);
 this.parent = parent;
 try
 imgBackgound = Image.createImage("/images/area03_bkg0.png");
 imgBackgoundX = this.getWidth() - imgBackgound.getWidth();
 imgBackgoundY = this.getHeight() - imgBackgound.getHeight();
 catch(Exception e)
 System.out.println(e.getMessage());
 * starts thread
 public void start()
 mTrucking = true;
 Thread t = new Thread(this);
 t.start();
 * stops thread
 public void stop()
 mTrucking = false;
 public void play()
 try
 InputStream is = getClass().getResourceAsStream("/sounds/scale.mid");
 player = Manager.createPlayer(is, "audio/midi");
 player.setLoopCount(-1);
 player.prefetch();
 player.start();
 catch(Exception e)
 System.out.println(e.getMessage());
 public void run()
 Graphics g = getGraphics();
 play();
 while (true)
 tick();
 input();
 render(g);
 * responsible for object movements
 private void tick()
 * response to key input
 private void input()
 int keyStates = getKeyStates();
 if ((keyStates & LEFT_PRESSED) != 0)
 imgBackgoundX++;
 if (imgBackgoundX > 0)
 imgBackgoundX = 0;
 if ((keyStates & RIGHT_PRESSED) != 0)
 imgBackgoundX--;
 if (imgBackgoundX < this.getWidth() - imgBackgound.getWidth())
 imgBackgoundX = this.getWidth() - imgBackgound.getWidth();
 * Responsible for the drawing
 * @param g
 private void render(Graphics g)
 g.drawImage(imgBackgound, imgBackgoundX, imgBackgoundY, Graphics.TOP | Graphics.LEFT);
 this.flushGraphics();
}

You can also try to provide a greater Priority to your player thread so that it gains the CPU time when ever it needs it and don't harm the playback.
However a loop in a Thread and that to an infinite loop is one kind of very bad programming, 'cuz the loop eats up most of your CPU time which in turn adds up more delays of the execution of other tasks (just as in your case it is the playback). By witting codes bit efficiently and planning out the architectural execution flow of the app before start writing the code helps solve these kind of issues.
You can go through [this simple tutorial|http://oreilly.com/catalog/expjava/excerpt/index.html] about Basics of Java and Threads to know more about threads.
Regds,
SD
N.B. And yes there are more articles and tutorials available but much of them targets the Java SE / EE, but if you want to read them here is [another great one straight from SUN|http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html] .
Edited by: find_suvro@SDN on 7 Nov, 2008 12:00 PM

V$undostat and maxqueryid

Similar Messages

Maybe you are looking for