Skip Navigation
Expand
When incident archiving is enabled, what happens with my incident-related data?
Answer ID 5030   |   Last Review Date 07/22/2019

When incident archiving is enabled, what happens with my incident-related data?

Environment:

Archiving incidents from your Oracle B2C Service database
Oracle B2C Service, all versions

Resolution:

When an incident is archived, data associated with that incident is transformed from a relational structure – where incident data is distributed across multiple, related tables – into a single XML file.  Records from the following tables are removed from the database and combined to form this XML file.

Records that are removed from the database and are archived:
 Records  Additional information
  incidents
 A record from this table represents a single incident. 
  threads  Zero to many threads records are associated with the incident record.
  fattach  Zero to many fattach records are related to the incident record.  NOTE: this table does not contain the file attachments, but instead contains references to any attachments’ locations.  Attachments themselves only ever exist on file attachment storage.
  transactions  One to many transactions records are associated with the incident, and they represent all of the transactions that have occurred with regard to the incident record.
  time_billed  Zero to many time_billed records are associated with the incident record.
  inc2contacts  One to many inc2contacts records are associated with the incident record.
  system attributes  System attributes that have a relationship with the incidents table will also be included in the incidents XML file.


The resulting XML file is stored on file attachment storage (FAS), a more economical form of storage ideal for this type of lower-value data.  A record of the archived incident is created in the archived_incidents table which serves as an index to its FAS location.  Archived incidents can be accessed via the Archive Console (see How to access and use the archive console).

Given their ancillary purpose, records from many other tables in the database that are associated with an archived incident are removed from the database or de-referenced from the archived incident without being archived, ensuring that all related data is properly cleared from the database.  Tables containing ancillary data are listed below.

Records are removed from the database but are not archived
bounced_msgs
channel_response_queues
chats
cloud_results
cobrowse_sessions
document_tags
gap_tree
inc_best_answers
inc_bounced_msgs
inc_performance
incident_draft_resp2fattach
incident_fattach_log
incidents_draft_resp2fattach
integration_errors
kf_sa_log
labels
ma_trans
mail_queue
mail_recipients
message_trans
milestone_instances
notes
offer_trans
osn_incident_conversations
phrases
question_sessions
queue_stats
rule_alerts
rule_log
tasks
tmp_keyword
user_trans
visibility

For additional information about any of the tables listed above, consult the Data Dictionary (see Accessing the Data Dictionary).

Once an incident is archived and transformed into an XML file, it cannot be reversed and cannot be re-inserted into the database.  While the XML format allows for hierarchical storage of the related data in a compressed form, it is not possible to easily extract it and re-insert it into the database.  For this reason, ensure that your archiving settings are tuned to archive those incidents expected to be accessed infrequently.

Available Languages for this Answer:

Notify Me
The page will refresh upon submission. Any pending input will be lost.