Jump to content

Is this report indicating an issue with my server ?


msizec
 Share

Recommended Posts

hello,

 

Theres a report that semmes to indicate that something is going wrong in ERA. In french, its called : "File d'attente des journaux du serveur". Its the 5th report in the "server performance" group.

 

Can you give me a hint on what's need to be done/check ?

post-11865-0-78881900-1464963113_thumb.png

Link to comment
Share on other sites

  • ESET Staff

This report may indicate problems with ERA database. It is either not working properly or your ERA server is receiving data faster than it is able to handle (but that would be growing much faster). Please check whether database is running. Also SERVER' trace.log will most probably contain specific database errors.  

Link to comment
Share on other sites

These are the only errors I can find (im using SQLSERVER) in a trace file But there is a bunch of it (since 02-02-16) so I don't think thats the culprit :

 

2016-06-06 00:00:12.46 spid51       Table 'tbl_log_rdsensor_newcomputers_status' will not be available during reorganizing index 'tbl_uk'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.47 spid51       Table 'tbl_log_functionality_products_status' will not be available during reorganizing index 'PK_tbl_log_functionality_products_status'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.47 spid51       Table 'tbl_log_activethreats_status' will not be available during reorganizing index 'PK_tbl_log_activethreats_status'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.48 spid51       Table 'tbl_policies' will not be available during reorganizing index 'PK_tbl_policies_policy_id'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.48 spid51       Table 'tbl_static_object_changes' will not be available during reorganizing index 'tbl_static_object_changes$transaction_id'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.48 spid51       Table 'tbl_log_eesvirusdb_status' will not be available during reorganizing index 'PK_tbl_log_eesvirusdb_status'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.48 spid51       Table 'tbl_log_exportedconfiguration_event' will not be available during reorganizing index 'PK_tbl_log_exportedconfiguration_event'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.49 spid51       Table 'tbl_log_scan_event' will not be available during reorganizing index 'sui'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.49 spid51       Table 'tbl_static_object_changes' will not be available during reorganizing index 'tbl_static_object_changes$object_uuid'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.49 spid51       Table 'tbl_log_apps_currentversion_status' will not be available during reorganizing index 'PK_tbl_log_apps_currentversion_status'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.49 spid51       Table 'tbl_automation_server_tasks' will not be available during reorganizing index 'PK_tbl_automation_server_tasks_task_uuid'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.50 spid51       Table 'tbl_dashboards' will not be available during reorganizing index 'PK_tbl_dashboards_dashboards_id'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.50 spid51       Table 'tbl_log_security_product_status_snapshot' will not be available during reorganizing index 'sui'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.50 spid51       Table 'tbl_log_threat_event' will not be available during reorganizing index 'tbl_uk'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.50 spid51       Table 'tbl_log_threat_event' will not be available during reorganizing index 'sui'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.51 spid51       Table 'tbl_static_object_ids' will not be available during reorganizing index 'PK_tbl_static_object_ids_object_id'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.52 spid51       Table 'tbl_log_scan_event' will not be available during reorganizing index 'tbl_uk'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.52 spid51       Table 'tbl_log_quarantine_content_status' will not be available during reorganizing index 'PK_tbl_log_quarantine_content_status'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.53 spid51       Table 'tbl_log_performance_server_event' will not be available during reorganizing index 'idx_gIndex1'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.57 spid51       Table 'tbl_log_scan_event' will not be available during reorganizing index 'idx_gIndex1'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.58 spid51       Table 'tbl_log_task_server_status' will not be available during reorganizing index 'sui'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.59 spid51       Table 'tbl_log_repository_software_status' will not be available during reorganizing index 'PK_tbl_log_repository_software_status'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.62 spid51       Table 'tbl_log_task_detail_agentdeployment_status' will not be available during reorganizing index 'sui'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.63 spid51       Table 'tbl_log_functionality_problemsdetails_status' will not be available during reorganizing index 'PK_tbl_log_functionality_problemsdetails_status'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.
2016-06-06 00:00:12.63 spid51       Table 'tbl_log_apps_installed_status' will not be available during reorganizing index 'PK_tbl_log_apps_installed_status'.  This is because the index reorganization operation performs inside a user transaction and the entire table is exclusively locked.

Edited by msizec
Link to comment
Share on other sites

I did search through the trace.log of ERA. There are lines of errors but I don't know what I'm looking for.

Theres a bunch of duplicate errors.

 

But the fact is I just updated ERA server and the queue seems to be almost empty now

Link to comment
Share on other sites

  • ESET Staff

Mentioned errors could have been reason for growing queue, but it should not take too much time. It was performing optimization of DB indexes that have exceeded specific fragmentation limit and is executed during databases cleanup, which is executed at midnight of SERVER's local time. Have you seen such errors only seconds pass midnight or during whole day?

 

Upgrading SERVER most probably interrupted running operation, which may help, but there is also chance it will be back after time.

Link to comment
Share on other sites

MantinK, these kind of sql errors happen only at midnight.

 

But 20hours after the server's update, the queue I mentionned in the top post is still empty.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...