To reproduce certain problems, Exasol support may ask you to send DDL statements for required tables and views. At this point you have two choices:
Start drilling around to find each and every required view / table etc. This may be a lot of work and may end up with some communication round trips in case you overlooked a dependency or two.
Skip all that and just send us the full DDL for all schemas in your database instance. Just let us sort out what is needed and what is not. Both options are not optimal.
The attachment of this article contains a procedure script (Lua) that can create DDL statements for recursive dependencies of a view. The DDL are presented as a single-column result-set and are ready for copy/paste into a text editor (or EXAplus) for saving.
execute script meta.create_DDL( 'DUT' , 'TRUNK' );
--DDL created by user SYS at 2017-11-14 09:44:59.554000
-- table dependencies --
CREATE SCHEMA "DUT";
CREATE TABLE "DUT"."TAB1"(
"I" DECIMAL(18,0) IDENTITY NOT NULL,
-- SYSTEM TABLE: SYS.EXA_METADATA
-- function dependencies --
function func( param decimal(3) ) returns decimal(3)
return sqrt(param) * (select max(i) from dut.tab1);
-- script dependencies --
CREATE LUA SCALAR SCRIPT "LUA_SCALAR" () RETURNS DECIMAL(18,0) AS
-- view dependencies --
--> level 2
-- SYSTEM VIEW: SYS.CAT
--> level 1
CREATE VIEW "DUT"."BRANCH"
as ( select * from exa_metadata, cat );
-- final query/view:
CREATE VIEW "DUT"."TRUNK"
select * from dut.tab1, dut.branch
where func(j) > lua_scalar()
This script is work in progress and has only seen minimal testing so far.
Things known not to work:
Virtual Schemas – It is unlikely we would be able to clone your remote system anyway.
Connections and IMPORT inside views – Like virtual schemas, it probably does not make much sense.
Dependencies inside scripts – This is branded 'dynamic SQL' and our engine can not determine those dependencies without actually executing the script with specific input.
SELECT dependencies inside functions – Just don't do that. Like with scripts, these dependencies to not show up in the system.
If your model contains any of the above and it turns out to be relevant for reproduction of a problem, you might have to revert to "Skip all that" above. The "Copy Database" script in create-ddl-for-the-entire-database may be of use then.
What data can you read using subconnections?
What data can you insert using subconnections?
How to establish parallel connections?
What about transactions in parallel mode?
What about transactions in parallel mode?
You can use subconnections to read or insert data in parallel from and into the EXASOL server. This will increase performance considerably.
Using this interface you can read/write data in parallel from different physical hosts or from different processes or in one process from different threads.
What data can you read using subconnections? You need a statement that produces a large result set. The result set can be then retrieved in parts from the parallel connections. For small results this interface has no advantage.
What data can you insert using subconnections? Like when reading data, using this interfaces only makes sense if you want to insert large amounts of data. You can simply insert rows into a table in EXASOL using a prepared insert statement. The data coming through the parallel connections will be put together by the server into the right table.
How to establish parallel connections? First you need a normal JDBC connection. On this you can use the method EnterParallel() to start operating with subconnections. You will receive connection strings for all new parallel connections you can start now. Start the subconnections with auto commit off. After this you can start reading or sending data, nearly like in a normal connection.
Attention: You can specify the maximum number of subconnections in EnterParallel() . This number may be reduced by the server because only one subconnection is allowed per database node. You have to establish the subconnections by using all connection strings received from Get Worker Hosts() . Subconnections can only be used after all connections have been established.
What about transactions in parallel mode? Start the subconnections with auto commit off. Commits should be made only on the main connection after the subconections have inserted all data and they have closed the prepared statements.
An Java example is attached. In the example a main connection reads the connection strings for the subconnections from the server. For each subconnection a thread is started that inserts a few rows. Commit is executed on the main connection. Then other threads read the data from the table.
In Exasol, the data is automatically evenly distributed among each node. This distribution is random, however. By specifying distribution keys, you can control how the data is distributed, which can lead to enormous performance improvements.