Traci,
Assuming the error message is accurate, the problem can usually be
solved with anything from restarting the EC to reinstalling it entirely.
It depends a little on what caused the registration to fail.
If you're curious, run this SQL find out summary information on EC
working sets (at least up to and including SP4):
USE RealsecurDB
SELECT setid, utilization, lastcount, rowstoload, convert(char
(19),loaddate), EC_Host
FROM stgWorkingset with (nolock)
ORDER BY setid
If you don't see your EC names in the 'EC_Host' column they are not
properly connected and registered to that set. I'm fairly certain sets
are allocated on a first-come, first-serve basis, so don't get surprised
if an EC shows up in a different set at different times.
To get detailed information of the staging tables (working set), try
this SQL (the code is clumsy, but it works). It's useful if you suspect
that events are getting 'stuck' in the database.
USE RealsecurDB
SET NOCOUNT ON
DECLARE @Alert int,
@Updates int,
@Response int,
@Parameter int
select @Alert = count(*)
from stg_AlertData1 with (NOLOCK)
select @Updates = count(*)
from stg_AlertUpdates1 with (NOLOCK)
select @Response = count(*)
from stg_AlertResponse1 with (NOLOCK)
select @Parameter = count(*)
from stg_AlertAVP1 with (NOLOCK)
SELECT 'Staging area 1', getutcdate()
SELECT 'Alert: ', @Alert, 'Updates: ', @Updates,
'Response: ', @Response, 'Parameter: ', @Parameter
select @Alert = count(*)
from stg_AlertData2 with (NOLOCK)
select @Updates = count(*)
from stg_AlertUpdates2 with (NOLOCK)
select @Response = count(*)
from stg_AlertResponse2 with (NOLOCK)
select @Parameter = count(*)
from stg_AlertAVP2 with (NOLOCK)
Select 'Staging area 2', getutcdate()
Select 'Alert: ', @Alert, 'Updates: ', @Updates,
'Response: ', @Response, 'Parameter: ', @Parameter
select @Alert = count(*)
from stg_AlertData3 with (NOLOCK)
select @Updates = count(*)
from stg_AlertUpdates3 with (NOLOCK)
select @Response = count(*)
from stg_AlertResponse3 with (NOLOCK)
select @Parameter = count(*)
from stg_AlertAVP3 with (NOLOCK)
Select 'Staging area 3', getutcdate()
Select 'Alert: ', @Alert, 'Updates: ', @Updates,
'Response: ', @Response, 'Parameter: ', @Parameter
select @Alert = count(*)
from stg_AlertData4 with (NOLOCK)
select @Updates = count(*)
from stg_AlertUpdates4 with (NOLOCK)
select @Response = count(*)
from stg_AlertResponse4 with (NOLOCK)
select @Parameter = count(*)
from stg_AlertAVP4 with (NOLOCK)
Select 'Staging area 4', getutcdate()
Select 'Alert: ', @Alert, 'Updates: ', @Updates,
'Response: ', @Response, 'Parameter: ', @Parameter
select @Alert = count(*)
from stg_AlertData5 with (NOLOCK)
select @Updates = count(*)
from stg_AlertUpdates5 with (NOLOCK)
select @Response = count(*)
from stg_AlertResponse5 with (NOLOCK)
select @Parameter = count(*)
from stg_AlertAVP5 with (NOLOCK)
Select 'Staging area 5', getutcdate()
Select 'Alert: ', @Alert, 'Updates: ', @Updates,
'Response: ', @Response, 'Parameter: ', @Parameter
Cheers,
Robert
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: 13 February 2005 18:09
To: [email protected]
Subject: [ISSForum] SP DB error. Pls help??
Hi everyone.
Relatively new to working with Real Secure Site Protector (1 month) and
new to this discussion forum/list. I am hoping someone can help me. I
have one of my consoles showing the SP DB "error" as its' status.
Below, I have included the details from the DB. Anyone have experience
with this or know where I can find the answer as to how to fix this??
Any guidance or help would be greatly appreciated!!!
Also, we have a lot of extra events coming in, so I am wondering if this
could be the catalyst for the error status?? The other 4 consoles I
monitor are NOT set to auto purge or auto maintenance.
Thank you for your valuable time,
Traci
License State Key Good
Sensor Status Error - Loading:Error: The event collector is not
properly registered to request a working set
Data File Status 26% Full
Transaction Log Status 1% Full
SQL Server Agent Status Running.
Data Load Status 0 rows were loaded on Feb 13 2005 10:39PM. 39
SensorData rows were rejected. 18 SensorDataAVP rows were rejected.
Analysis Purge Status Purge Status: Complete; LastUpdated: Feb 8 2005
12:01AM (GMT) Status Description: Complete. No errors.
SensorData Purge Status Purge Status: Complete; LastUpdated: Feb
8 2005 12:01AM (GMT) Status Description: Complete. No errors.
Data Used (MB) 767 MB
Metrics Last Loaded Feb 13 2005 7:00AM
Auto Maintenance Job Job Enabled; Last Run Succeeded; Last Run Time:
Feb 13 2005 10:32PM
Auto Purge Setting ON
Auto Maint Setting ON
Defragment Index Setting ON
Health Status Last Checked At 2005-02-13 22:47:12 (GMT)
Version 2.0 (SP 1.3:XPU 1.50)
Available XPU Yes
Last Installed XPU SP 1.3
Site Name w/held for security reasons
Install Date Jun 28 2004 11:27AM
XPU Date None
Option Flag Default
Logging Level Informational
Last Modified By Sensor Controller(w/held for security reasons)
at 2005-02-13 16:47:34.567(GMT)
_______________________________________________
ISSForum mailing list
[email protected]
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo/issforum
To contact the ISSForum Moderator, send email to [EMAIL PROTECTED]
The ISSForum mailing list is hosted and managed by Internet Security
Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
_______________________________________________
ISSForum mailing list
[email protected]
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo/issforum
To contact the ISSForum Moderator, send email to [EMAIL PROTECTED]
The ISSForum mailing list is hosted and managed by Internet Security Systems,
6303 Barfield Road, Atlanta, Georgia, USA 30328.
