Reproducing phantom processes

Reproducing phantom processes

Post by Mixalis Miliaraki » Sat, 07 Feb 1998 04:00:00



We managed to reproduce a phantom process using the following procedure:

1. Run a process from Unix (solaris 2.4) which is using bulk insert.
2. The process enters the DB and was locked by another process.
3. Stop the unix process by pressing Control-C, since it was locked.
4. Kill the same process from isql. The process was killed, but then
all        other processes which accessed the same table were blocked by
the        killed process.

--
===========================
Mixalis Miliarakis
DB Administrator
FORTHnet SA
Heraklio, Crete, Greece
===========================

 
 
 

Reproducing phantom processes

Post by Dinya » Sat, 07 Feb 1998 04:00:00


hi,
please specify the sybase version.
this could be the cause of a bug or sybase is just taking a long time to
clean up/release locks. i read somwhere in Sybooks, when i was looking for
'keepalive' that it can take sybase from 10 min to 2 hours to release locks
or cleanup after a killed process.  maybe u didn't wait long enough. how
long did u wait?
by specifying a version u'll help sole your prob much faster
reagrds
-dinyar


> We managed to reproduce a phantom process using the following procedure:

> 1. Run a process from Unix (solaris 2.4) which is using bulk insert.
> 2. The process enters the DB and was locked by another process.
> 3. Stop the unix process by pressing Control-C, since it was locked.
> 4. Kill the same process from isql. The process was killed, but then
> all        other processes which accessed the same table were blocked by
> the        killed process.

> --
> ===========================
> Mixalis Miliarakis
> DB Administrator
> FORTHnet SA
> Heraklio, Crete, Greece
> ===========================


 
 
 

Reproducing phantom processes

Post by Mixalis Miliaraki » Sat, 07 Feb 1998 04:00:00


The version is:
  SQL Server/11.0.2/P/Sun_svr4/OS 5.4/1/OPT/Tue Sep 10 14:03:23 PDT 1996

Running on:
  SunOS 5.5.1 Generic sun4u sparc SUNW,Ultra-2

Mihalis.


> hi,
> please specify the sybase version.
> this could be the cause of a bug or sybase is just taking a long time to
> clean up/release locks. i read somwhere in Sybooks, when i was looking for
> 'keepalive' that it can take sybase from 10 min to 2 hours to release locks
> or cleanup after a killed process.  maybe u didn't wait long enough. how
> long did u wait?
> by specifying a version u'll help sole your prob much faster
> reagrds
> -dinyar


> > We managed to reproduce a phantom process using the following procedure:

> > 1. Run a process from Unix (solaris 2.4) which is using bulk insert.
> > 2. The process enters the DB and was locked by another process.
> > 3. Stop the unix process by pressing Control-C, since it was locked.
> > 4. Kill the same process from isql. The process was killed, but then
> > all        other processes which accessed the same table were blocked by
> > the        killed process.

> > --
> > ===========================
> > Mixalis Miliarakis
> > DB Administrator
> > FORTHnet SA
> > Heraklio, Crete, Greece
> > ===========================

--
===========================
Mixalis Miliarakis
DB Administrator
FORTHnet SA
Heraklio, Crete, Greece
===========================
 
 
 

Reproducing phantom processes

Post by Raoul Bantua » Sat, 07 Feb 1998 04:00:00


dinyar,

you're right. in my previous project (systems 10 & 11 on SunOs), i used
to get phantom processes from PB connections. even if we reboot the
client PC and kill the process inside the server, the process would not
die. sometimes, since it is already the end of the working day, i just
left the connection there*. the following morning i'd find out
that it's gone. i think, it takes the server from 2-4 hours to kill
phantom processes.

raoul


> hi,
> please specify the sybase version.
> this could be the cause of a bug or sybase is just taking a long time to
> clean up/release locks. i read somwhere in Sybooks, when i was looking for
> 'keepalive' that it can take sybase from 10 min to 2 hours to release locks
> or cleanup after a killed process.  maybe u didn't wait long enough. how
> long did u wait?
> by specifying a version u'll help sole your prob much faster
> reagrds
> -dinyar


> > We managed to reproduce a phantom process using the following procedure:

> > 1. Run a process from Unix (solaris 2.4) which is using bulk insert.
> > 2. The process enters the DB and was locked by another process.
> > 3. Stop the unix process by pressing Control-C, since it was locked.
> > 4. Kill the same process from isql. The process was killed, but then
> > all        other processes which accessed the same table were blocked by
> > the        killed process.

> > --
> > ===========================
> > Mixalis Miliarakis
> > DB Administrator
> > FORTHnet SA
> > Heraklio, Crete, Greece
> > ===========================

--
Raoul Bantuas
DBA, MCI Colorado Springs
Phone: 719-535-6288

 
 
 

Reproducing phantom processes

Post by Bret Halfor » Sat, 07 Feb 1998 04:00:00


Hi Dinyar,

I believe what you read was more on the lines of:

If a client process exits without closing its port, the
TCP KEEPALIVE interval determines how long the network connection
will remain open.  The usual default for KEEPALIVE is 2 hours,
generally it should not be set lower than 10 minutes.  One the KEEPALIVE
interval expires, SQL Server is notified that the connection has been
killed and promptly cleans up the killed process.  The 10 minute to 2
hour delay in cleaning up the process comes at the network layer, not
within Sybase SQL Server.

Phantom processes are caused by problems in cleaning up the killed
process.

-bret


> hi,
> please specify the sybase version.
> this could be the cause of a bug or sybase is just taking a long time to
> clean up/release locks. i read somwhere in Sybooks, when i was looking for
> 'keepalive' that it can take sybase from 10 min to 2 hours to release locks
> or cleanup after a killed process.  maybe u didn't wait long enough. how
> long did u wait?
> by specifying a version u'll help sole your prob much faster
> reagrds
> -dinyar


> > We managed to reproduce a phantom process using the following procedure:

> > 1. Run a process from Unix (solaris 2.4) which is using bulk insert.
> > 2. The process enters the DB and was locked by another process.
> > 3. Stop the unix process by pressing Control-C, since it was locked.
> > 4. Kill the same process from isql. The process was killed, but then
> > all        other processes which accessed the same table were blocked by
> > the        killed process.

> > --
> > ===========================
> > Mixalis Miliarakis
> > DB Administrator
> > FORTHnet SA
> > Heraklio, Crete, Greece
> > ===========================

--
Bret Halford                    Imagine my disappointment
Sybase Technical Support        in learning the true nature            
3665 Discovery Drive            of rec.humor.oracle...
Boulder, CO 80303
 
 
 

Reproducing phantom processes

Post by Dinya » Sun, 08 Feb 1998 04:00:00


hi,
Ooops. sorry.  i stand corrected.
regards
-dinyar


> Hi Dinyar,

> I believe what you read was more on the lines of:

> If a client process exits without closing its port, the
> TCP KEEPALIVE interval determines how long the network connection
> will remain open.  The usual default for KEEPALIVE is 2 hours,
> generally it should not be set lower than 10 minutes.  One the KEEPALIVE
> interval expires, SQL Server is notified that the connection has been
> killed and promptly cleans up the killed process.  The 10 minute to 2
> hour delay in cleaning up the process comes at the network layer, not
> within Sybase SQL Server.

> Phantom processes are caused by problems in cleaning up the killed
> process.

> -bret


> > hi,
> > please specify the sybase version.
> > this could be the cause of a bug or sybase is just taking a long time to
> > clean up/release locks. i read somwhere in Sybooks, when i was looking for
> > 'keepalive' that it can take sybase from 10 min to 2 hours to release locks
> > or cleanup after a killed process.  maybe u didn't wait long enough. how
> > long did u wait?
> > by specifying a version u'll help sole your prob much faster
> > reagrds
> > -dinyar


> > > We managed to reproduce a phantom process using the following procedure:

> > > 1. Run a process from Unix (solaris 2.4) which is using bulk insert.
> > > 2. The process enters the DB and was locked by another process.
> > > 3. Stop the unix process by pressing Control-C, since it was locked.
> > > 4. Kill the same process from isql. The process was killed, but then
> > > all        other processes which accessed the same table were blocked by
> > > the        killed process.

> > > --
> > > ===========================
> > > Mixalis Miliarakis
> > > DB Administrator
> > > FORTHnet SA
> > > Heraklio, Crete, Greece
> > > ===========================

> --
> Bret Halford                    Imagine my disappointment
> Sybase Technical Support        in learning the true nature
> 3665 Discovery Drive            of rec.humor.oracle...
> Boulder, CO 80303

 
 
 

Reproducing phantom processes

Post by Bret Halfor » Thu, 12 Feb 1998 04:00:00



> We managed to reproduce a phantom process using the following procedure:

> 1. Run a process from Unix (solaris 2.4) which is using bulk insert.
> 2. The process enters the DB and was locked by another process.
> 3. Stop the unix process by pressing Control-C, since it was locked.
> 4. Kill the same process from isql. The process was killed, but then
> all        other processes which accessed the same table were blocked by
> the        killed process.

This procedure does not result in phantoms (for me, anyway) under ASE
11.5 on Solaris.

--
Bret Halford                    Imagine my disappointment
Sybase Technical Support        in learning the true nature            
3665 Discovery Drive            of rec.humor.oracle...
Boulder, CO 80303

 
 
 

1. Phantom SQL Server Process Locks My App

I'm using Borland C++ Builder 4 and its TQuery component to try to work with
a SQL Server 7.0 database via ODBC from Win98.  My goal is to completely
delete and then repopulate four tables (from external flat files) so that no
one can do anything with these four tables while they're loading.  My
approach is the following:

Create four TQuery objects all using the same database.
Use one of the TQuery objects to execute the following:
    "set transaction isolation level serializable"
    "begin transaction"
Use each TQuery object to "delete from <table>" in turn.
Prepare a different "insert" statement in each of the four TQuery objects.
Process the flat files, inserting as you go.
Use one of the TQuery objects to "commit work".

The deletion of the four tables goes fine, but when the first (or something
close to the first) "insert" statement is run, the process hangs.  Looking
at the SQL Server Enterprise Manager, I see that there are more than one
"spid" processes accessing my database (typically, three [I think]).  One
spid is WAITing for a table lock, held by another, to be released.

Shouldn't there be only one SQL Server process running?  How can a single
database connection wait for itself?  Shouldn't all four prepared statements
share the same spid?

Thanks for any assistance you can render!

2. Listener error 12500-12540: Java OCI and Oracle 8.1.6

3. Phantom dbsnmp processes?

4. Sybase anyware problem

5. ghost/phantom processes

6. Value / row level locking with disconnected recordsets

7. NT 3.5 phantom processes

8. Need to update init file for rollback segment?

9. how to handle phantom processes

10. Phantom processes

11. NT SQLServer/Named Pipes/Phantom Processes

12. Kill a Phantom Process in Universe

13. Convert To Phantom Process - D3 Aix