Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
About a month ago, our virtual server that houses Qlik encountered a low drive situation where it hit less that 10% available. While I figured 25GB was still plenty, Qlik didn't like it, and it crashed on me. We recovered the entire virtual machine from a backup, I cleared out TONS of old logs, and freed up over 80GB of space. Ever since this event, several of my monitoring apps won't reload. Most of their error logs are showing a version of this:
20200715T164146.440-0700 0557 SELECT * FROM "public"."view_audit_activity_audit_security"
20200715T164146.440-0700 0558 WHERE entry_timestamp >= '2020-04-15 00:00:00'
20200715T164147.171-0700 Error: Field 'entry_timestamp' not found
I figured since we were running on the November 2019 release, and I needed to perform an upgrade, things would resolve themselves when I went to February 2020. I've done that this past Monday, and it's still having issues.
So here's my question: I believe there are QVDs or other supporting data on the Qlik server that I can remove & the apps will rebuild the data sources that they need. Based on that, can someone point me to links or information on what to remove? I've done multiple searches, but feel like I can't find specifically what is necessary.
Thank you in advance, and I appreciate your efforts to guide me!
Apps Currently Failing:
Successful Apps:
Hey @bjendrick ,
Since the field entry_timestamp comes from the QLogs database, which is a product of the Centralized Logging capabilities, then my guess of things it things is that somehow there exists a QLogs database but the underlying tables which ought to be there are no longer there. Most of those apps have effectively dual modes, they can log from files on disk or DB based logs. The default value for this is auto:
The question for you would be, do you intend to use Centralized Logging? Or is that functionality either irrelevant or only a nice to have?
For your current exception, I would do the following:
At this stage the apps will not load from the database and moreover cannot sense the credentials are bad.
Personally I view Centralized Logging as a nice to have rather than a have-to-have so would do step 1 for any environment. The physical logs on disk are the system of record and thus should be the sole source of usage data.
* This solution will not scope to the Sense System Performance Analyzer app. It depends on Centralized Logging for some unique data points which aren't otherwise available in the logs on disk.
If you do intend to have Centralized Logging enabled, then I would re-configure it like so:
At this stage, a restart of services would get things to fully initialize. If going this route then ignore step 3 above / adjust step 3 to use the new reader password.
Cheers
Wow... thank you! I don't have time to tackle this tonight, but I'll jump into it first thing tomorrow morning, and based on what I read, that should do the trick. Based on the Performance app, I might just remove that. I can't honestly say that I've done anything with it ever (other than "oooh, look, a new app"). Thank you, thank you, thank you, and I'll report back!