Grouper Users - Open Discussion List

[Chris Hyzer <>]

I see :)  I have no idea.  Nuclear option is kill sessions and truncate the 
table.  Second choice that should work is create another logs temp table as 
select recent rows from daemon logs table, then truncate daemon logs table, 
then move rows back, and drop the logs temp table...

I think oracle can choke on removing too many records at once, might need to 
have the job delete records in batches to avoid this issue.

Thanks,
Chris

-----Original Message-----
From: Scott Koranda 
[mailto:]
 
Sent: Wednesday, October 14, 2015 8:23 AM
To: Chris Hyzer
Cc: grouper-users
Subject: Re: [grouper-users] loader job MAINTENANCE_cleanLogs

Hi,

> You cant connect to the DB and run a query?  

I can, but the priority is to get the sandbox running again
and not take up any more of the DBA's time. The DBA is
assiting me but has other tasks to which he must attend.

> I meant how
> many rows for the MAINTENANCE_cleanLogs job running a few
> minutes ago.

I understand and will check again when the table is in a
better state.

> My hunch is that you ran it previously, killed it, and the
> process is still running on oracle.  Now you run it again,
> trying to delete the same rows and thd previous run is
> locking it?  Maybe try to kill all those session, and
> manually try to delete some of the records starting with
> oldest?  Might have to do this a few times before the table
> gets under control and the job from grouper will work again?

No, I worked with the DBA and we made sure all queries on any
Grouper tables were killed. The tables were completely
inactive.

Then I issued the MAINTENANCE_cleanLogs job using GSH.

At that point we saw the four (4) 'delete from
grouper_loader_log where last_updated < :1' queries across 4
SID,SERIAL# combinations in the STATE and WAIT_CLASS as noted
before.

Hence my question.

Thanks,

Scott

> 
> Thanks, Chris
> 
> 
> -----Original Message----- From: Scott Koranda
> [mailto:]
>  Sent: Wednesday, October 14,
> 2015 8:14 AM To: Chris Hyzer Cc: grouper-users Subject: Re:
> [grouper-users] loader job MAINTENANCE_cleanLogs
> 
> Hi,
> 
> > Not sure.  How many records do you see for the job in
> > grouper_loader_log?  You should see one.  
> 
> I cannot say--the reason for the MAINTENANCE_cleanLogs job
> is to try and delete a large number of rows from a
> grouper_loader_job table that is too large (due to
> unimportant reasons and on a development system). The
> priority is to get the table under control and the sandbox
> system back up.
> 
> Later when the sandbox is functional again I can check.
> 
> > This is not threaded or anything...
> 
> I see the four (4) session/serial# combinations and all 4
> are in the STATE 'WAITING'. Three (3) of the four have
> WAIT_CLASS 'Idle' and one has WAIT_CLASS 'User I/O'. The
> three (3) that are idle are waiting on EVENT 'PX Deq Credit:
> send blkd' while the one that is in 'User I/O' has EVENT 'db
> file sequential read'.
> 
> Again, this is not a priority--I am mostly curious why a
> single loader job would apparently generate four (4)
> identical queries.
> 
> Thanks,
> 
> Scott
> 
> > 
> > Thanks, Chris
> > 
> > -----Original Message----- From:
> > 
> > [mailto:]
> >  On Behalf Of
> > Scott Koranda Sent: Tuesday, October 13, 2015 4:03 PM To:
> > grouper-users Subject: [grouper-users] loader job
> > MAINTENANCE_cleanLogs
> > 
> > Hi,
> > 
> > When I use GSH to run
> > 
> > loaderRunOneJob("MAINTENANCE_cleanLogs");
> > 
> > I then see in my Oracle database 4 sessions with this
> > SQL_TEXT:
> > 
> > delete from grouper_loader_log where last_updated < :1
> > 
> > Why do I see 4 of those?
> > 
> > Note that all Grouper processes are stopped. The only
> > process connected to the database is the GSH.
> > 
> > Thanks,
> > 
> > Scott