Date: Fri, 29 Mar 2024 06:32:27 +0000 (UTC) Message-ID: <1792472874.5633.1711693947309@ip-10-0-1-161.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5632_1238254463.1711693947304" ------=_Part_5632_1238254463.1711693947304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
You may want to delete historical performance da= ta if the Uptime Infrastructure Monitor Archive process has timed out and d= ata older than the Archive Policy still exists in the data store. You= may also choose to manually delete historical performance data t= o free up the threads for regular monitoring that the Uptime Infrastructure= Monitor Archive process would occupy. Another reason to manually del= ete historical performance data is to shrink the size of the DataStore whic= h is covered in the Shrinking your MySQL DataStore knowledge base article.
Onc= e you know the oldest data sample, go to the Historical Data Purge Scripts<= /a> p= age and download the MySQL trim script you want to run i.e. Ad-hoc, Pr= ocedure or Use Archive Settings.
Choose a date for which all data samples collected before this day w= ill be deleted. It is strongly recommended that deletions are complet= ed in small chunks (e.g. 2 weeks or 1 month at a time) rather than attempti= ng one large delete statement, so if the oldest data in the data store is f= rom July 1, 2014, choose July 15, 2014 as the day to delete from.
You should verify the historical performance data has been deleted b= y running a performance graph or report in the Uptime Infrastructure Monito= r UI or simply running the Datastore Profile script again.
If you encounter any issues or have any questions regarding this process= please do not hesitate to contact uptime-support@idera.com<= /a> for guidance.
See related articles for DataStore running on MS SQL or&nb= sp;Oracle.