It has been suggested in an answer to another question that I might be able to determine how to script the running of the Database Designer, by monitoring it's queries/statements (see https://community.vertica.com/vertica/topics/how_can_i_script_the_running_of_the_database_designer).
Assuming that this is a more general approach - that of being able to monitor Vertica queries/statements as they exectute, in what ways can this be done in Vertica?
How I can monitor Database Designer queries/statements when it runs?
+1
+2Hi Neil,
You can view queries in the "query_requests" system table. Also in the Vertica log file.
That said, please be aware that reverse-engineering Vertica in this way is very much not supported. AdminTools's curses and command-line scripting interfaces are the only supported ways to run the DBD currently. If we thought that the DBD internals were ready to be used directly, we would have exposed them :-) Be aware that this approach may yield bizarre/unexpected failures; that anything you learn is certain to break if applied to future Vertica releases; and that, if you manage to break your installation somehow, our support folks will ask you when your most-recent backup was.
We're keenly aware of the demand for a real API here. So stay tuned :-)
Adam
You can view queries in the "query_requests" system table. Also in the Vertica log file.
That said, please be aware that reverse-engineering Vertica in this way is very much not supported. AdminTools's curses and command-line scripting interfaces are the only supported ways to run the DBD currently. If we thought that the DBD internals were ready to be used directly, we would have exposed them :-) Be aware that this approach may yield bizarre/unexpected failures; that anything you learn is certain to break if applied to future Vertica releases; and that, if you manage to break your installation somehow, our support folks will ask you when your most-recent backup was.
We're keenly aware of the demand for a real API here. So stay tuned :-)
Adam
+1Hi!
IMHO "query_requests" doesn't good for real-time monitoring or profiling.
1. For motoring active queries use in SESSIONS table (the delay much less than QUERY_REQUESTS table)
2. For real-time monitoring long-running queries use in QUERY_PLAN_PROFILES table
3. How to View Real-time Profiling Data
IMHO "query_requests" doesn't good for real-time monitoring or profiling.
1. For motoring active queries use in SESSIONS table (the delay much less than QUERY_REQUESTS table)
2. For real-time monitoring long-running queries use in QUERY_PLAN_PROFILES table
3. How to View Real-time Profiling Data
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
