Good morning.
I am making a function that connects to Oracle from JDBC and executes a query.
The number of query statements to be executed is about 50.
I looked for several examples, but most of them are examples that execute only one, and even this is only executed by putting the query in a variable.
I think it is impossible to put all 50 queries in a variable.
Among these, there is an option called allowMultiQueries=true in mysql, but it does not appear to be in oracle.
';', which means the end of the query syntax. Is there any other way to perform a multi-line query other than parsing based on?
Related
I have a few queries that I am running and I would like to view some sort of query plan for a given query. When I add "explain" before the query, I get a long (~4,000 lines) result that is not possible to interpret.
The MAL plan exposes all parallel activity needed to solve the query. Each line is a relational algebra operator or catalog action.
You might also use PLAN to get an idea of the output of the SQL optimizer.
Each part in the physical execution plan that'll be executed in parallel is repeated the same number of times as the number of cores you have in the result of EXPLAIN. That's why EXPLAIN can sometimes produce a huge MAL plan.
If you just want to have an idea of how are query is handled, you can force MonetDB to generate a sequential MAL plan, then at least, you get rid of the repetitions. For this, you can change the default optimiser pipe line to, e.g., 'sequential_pipe'. This can be done both in a client (it works then only for this client session), or in a server (it works then for the whole server session). For more information: https://www.monetdb.org/Documentation/Cookbooks/SQLrecipes/OptimizerPipelines
What are the differences between Connection#exec_params and Connection#exec_prepared? It seems like they both require the same kinds of input and they both perform the same action. Why would someone choose one versus the other?
You can use exec_prepared to optimize SQL query, see documentation.
exec_params lets you execute specified SQL query with binded parameters. exec_prepared lets you execute prepared (parsed, optimized etc) SQL query specified by its string identificator/name which you have got earlier.
If you make a lot of similar SQL select queries and difference is parameter values, you can make it effectively by preparing SQL statement once (you receive it identifier) and execute it with different parameters multiple times.
I want to use the count(*) result from a Hive Query as input for a second hive query. The query is simplified as:
set LIM = SELECT count(*) from default.mytable* 0.8;
select * from default.mytable LIMIT ${hiveconf:LIM};
The above code will lead to an error as the first query does not get executed and there the LIM variable will not get substituted with a numeric value.
Is there a way to force Hive to substitute the variable LIM so that I have a numeric value in the second query?
## WARNING - verbose explanation follows; the short answer is "no way" ##
In terms of IT Architecture, this kind of tricks is not done in the database tier but in the application tier.
Since I don't know nuthin' about your Teradata stack (fondly nicknamed "taratata" by some of your French-speaking colleagues) I'll take the Oracle stack as an example.
A. Inside a PL/SQL block, you can retrieve the (scalar) result of a query into a variable, and use it later -- as an input bind variable in a prepared statement, or as a way to build dynamically a string to be parsed dynamically as a SQL query. That PL/SQL block an "application", with application logic of arbitrary complexity; it just happens to run inside an Oracle session, on the same host that also runs the database tier.
B. Inside the SQL*Plus client (and maybe compatible tools e.g. SQL Developer) you can use a weird syntax to retrieve a value in a kind of macro-variable, that can be used to stuff the value as-is in further SQL queries. That trick allows some crude "application" logic to be applied to an otherwise static SQL script, client-side. But that is clearly a non-portable trick.
Bottom line - since Hive has no procedural language, and will probably (hopefully) never have one, the best way to do what you want would be to develop your own custom Hive client all by yourself, with whatever business logic you want. After all, there must be thousands of people around the world who are developing Java code to access Hive with JDBC, so you would not be alone...
Well.. you can do that if you are comfy with writing a shell script.
Take the query output and store it into a variable & use the variable for your second query.
I have a vey huge query. It is rather large, so i will not post it here(it has 6 levels of nested queries with ordering and grouping). Query has 2 parameters that are passed to it via PreparedStatement.setString(index, value). When I execute my query through SQL Developer(replacing query parameters to actual values before it by hand) the query runs about 10 seconds and return approximately 15000 rows. But when I try to run it through java program using PreparedStament with varibales it fails with ORA-01652(unable to extend temp segment). I have tried to use simple Statement from java program - it works fine. Also when I use preparedStatement without variables(don't use setString(), but specify parameters by hand) it works fine too.
So, I suspect that problem is in PreparedStatemnt parameters.
How does the mechanism of that parameters work? Why simple statement works fine but prepared one fails?
You're probably running into issues with bind variable peeking.
For the same query, the best plan can be significantly different depending on the actual bind variables. In 10g, Oracle builds the execution plan based on the first set of bind variables used. 11g mostly fixed this problem with adaptive cursor sharing, a feature that creates multiple plans for different bind variables.
Here are some ideas for solving this problem:
Use literals This isn't always as bad as people assume. If the good version of your query runs in 10 seconds, the overhead of hard-parsing the query will be negligible. But you may need to be careful to avoid SQL injection.
Force a hard-parse There are a few ways to force Oracle to hard-parse every query. One method is to call DBMS_STATS with NO_INVALIDATE=>FALSE on one of the tables in the query.
Disable bind-variable peeking / hints You can do this by removing the relevant histograms, or using one of the parameters in the link provided by OldProgrammer. This will stabilize your plan, but will not necessarily pick the correct plan. You may also need to use hints to pick the right plan. But then you may not have the right plan for every combination of inputs.
Upgrade to 11g This may not be an option, but this issue is another good reason to start planning an upgrade.
I have an Oracle 9 database from which my Delphi 2006 application reads data into a TSimpleDataSet using a SQL statement like this one (in reality it is more complex, of course):
select * from myschema.mytable where ID in (1, 2, 4)
My applications starts up and executes this query quite often during the course of the day, each time with different values in the in clause.
My DBAs have notified me that this is creating execessive load on the database server, as the query is re-parsed on every run. They suggested to use bind variables instead of building the SQL statement on the client.
I am familiar with using parameterized queries in Delphi, but from the article linked to above I get the feeling that is not exactly what bind variables are. Also, I would need theses prepared statements to work across different runs of the application.
Is there a way to prepare a statement containing an in clause once in the database and then have it executed with different parameters passed in from a TSimpleDataSet so it won't need to be reparsed every time my application is run?
My answer is not directly related to Delphi, but this problem in general. Your problem is that of the variable-sized in-list. Tom Kyte of Oracle has some recommendations which you can use. Essentially, you are creating too many unique queries, causing the database to do a bunch of hard-parsing. This will spike the CPU consumption (and DBA blood pressures) unnecessarily.
By making your query static, it can get by with a soft-parse or perhaps no parse at all! The DB can then cache the execution plan, the DBAs can deal with a more "stable" SQL, and overall performance should be improved.