When does an event EXACTLY go to the 'Transferred' state?

[Aditya Raute]

I read in the documentation that the Event [sysevent] records can be present in four states. Of these, I'm having trouble understanding what a 'Transferred' state is.

• When does an event go to the transferred state?
• Why would the Event Queue change?
• What scenarios will this be needed in? 

Sadly the documentation was a bit too confusing for me. Please assist.

[Maik Skoddow · Accepted solution]

Hi

the sysevent table is a rotated table. That means that under the hood, the virtual table sysevent is split up in several physical tables according to the rotation configuration. In ServiceNow all these physical tables are called "Shards".

With a time based pointer ServiceNow writes only to the current Shard which is okay in most of the cases. But imagine there are unprocessed events during a Shard change. To keep the performance gain we have with table rotation, it would make no sense to join the new Shard with the old Shard for reading operations. Therefore ServiceNow copies all unprocessed events from the old Shard to the new Shard and sets the events in the old Shard to the state "transferred".

For a better understanding read the following excellent article: https://community.servicenow.com/community?id=community_article&sys_id=f6578d61db502810fb115583ca961...

Maik

[AndyvanStei]

So when looking at the Sys Event table and you see 'transfered', you are looking at an old Shard? 

[Nisar3]

So does that mean those in "transferred" state are not processed?

[AndyvanStei]

For me it was simple, I exclude them from the scan, since they have been rotated to the other Shard.