I’m assuming if it’s an on-prem Orchestrator and you’re unable to work on the SQL Database means that someone else manages the infrastructure? I would probably talk with them to see if they can dump a subset of the data for you from the database (assuming the logs are not routed anywhere else as well).
From an infrastructure perspective - Would also see if they and redirect the logs (Using NLog in Orchestrator) to direct the logs to another repository Elastic Search, UiPath’s Insights, Splunk, Snowflake, another DB, etc. this would free the data up without putting additional load on the Orchestrator DB, it would also allow general maintenance to be performed by cleaning up older records in Orchestrator.
It’s not ideal, but from the Logs UI you can export the data as a CSV. It doesn’t give you all the fields nor the rawmessage meta data, but it is something. If you can filter the logs further (if you know the machine, process, identity) that could help trim it down for you.
Our DB used to be 8M records on the logs table, didn’t notice any performance issues, but we’ve since introduced scheduled jobs to only maintain the last 15-30 days depending on the table. Everything is sent to Splunk where we keep it for a few months and generate any summary data we need for further retention.