Table of Contents Scope The error we are addressing is c onnection lost after the session runs out of memory. The error was encountered while running a Lua script on Exasol version 6.2.11. Just so you are aware, the DBRAM is currently split in two: Heap (showing as MEM in profiling) and other (for background processing). This article looks at both potential errors: 1. SESSION out of memory; 2. SYSTEM out of memory.  Version 6.1.x had additional issues, such as   JDBC has high memory usage for encrypted communication. If you are running version 6.1.x and seeing high memory usage for JDBC encrypted communication, a workaround is to set encryption=0. Diagnosis Before going into detail, please review https://www.exasol.com/support/browse/EXASOL-2787 that addresses one of the reasons you may receive the error:  Connection lost after session running out of memory If you are experiencing session out of memory running joins with the USING clause (versus joins with the ON clause), be aware that joins with the USING clause have higher resource consumptions and processing efforts than the join with the ON clause. Changing your join USING to join ON can reduce the query's claim on total resources and can prevent the session from running out of heap memory.  The above information and much more are covered on our best practices page: https://docs.exasol.com/performance/best_practices.htm. Continuing on, There are two heap parameters controlling memory usage:  maxProcessHeapMemory  and  maxSystemHeapMemory.    Explanation In Exasol all SQL session and database management processes share a default system heap memory of 32 GB, which is part of DBRAM. If this limit is reached, the topmost consuming sessions are terminated and deliver the error message "SYSTEM running out of heap memory". At the session-level, the ProcessHeapMemory parameter impacts the session's working memory (doesn't include the cached tables) of the SQL running and all UDF processes of that query.  A query might fail with a "SESSION out of memory" if it uses more than the specified maxProcessHeapMemory. Recommendation Scenario: W hen inserting into a distributed table with several hundred varchar columns, heap memory allocation may lead to session out of memory. See https://www.exasol.com/support/browse/EXASOL-2512. Exasol sets the session-level heap to 4GB, which is optimized to keep rouge queries from over-consuming resources needed by other queries. Changing the session-level heap impacts all queries and potentially can impede performance if your workload is waiting on cores and RAM consumed by particular resource-intensive queries. If your use case requires more heap memory, you can change  the maxProcessHeapMemory parameter which controls the session-level heap allocation. The workaround is to change: -maxProcessHeapMemory=4096 to -maxProcessHeapMemory=8192 Be aware that changing this parameter means every connection can now use up to 8192 MB. Your allocated resources will determine whether this is an appropriate action to take. You can make this change via  EXAoperation  (changing "Extra DB Parameters" in  ExaSolution ) which would also fix other queries affected by the bug. This requires a short downtime. Here  is the link which explains in detail how it can be done. https://docs.exasol.com/administration/on-premise/manage_database/edit_database.htm   Scenario:   If the 32 GB system heap memory limit is reached, the topmost consuming SQL sessions are terminated and deliver the error message "system running out of heap memory". The workaround is to increase the maxSystemHeapMemory, like this: -maxSystemHeapMemory=65536 Here  is the link which explains in detail how it can be done. https://docs.exasol.com/administration/on-premise/manage_database/edit_database.htm Additional References https://www.exasol.com/support/browse/EXASOL-2787 https://www.exasol.com/support/browse/EXASOL-2604 https://www.exasol.com/support/browse/EXASOL-2512     We're happy to get your experiences and feedback on this article below! 
View full article
If you want to implement Column Level Security in addition to Row Level Security, this example shows you how this can work using Virtual Schemas
View full article
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. 
View full article
This article gives general information about Exasol's indices.
View full article
Estimating work duration when doing reorganizations within Exasol.
View full article
Exasol cluster enlargement (adding nodes) and what you need to know if you are seeing impeded performance.
View full article
This article gives an example of how Exasol's Skyline Feature can be used
View full article
Background This article describes the automatic process to move data after node failures Symptoms A typical data volume of a database has a redundancy of 2. With this configuration, data on each volume node have one redundancy copy on another volume node. Thus, the failure of one volume node can be handled without data loss. A typical database configuration consists of some active database nodes and one or more reserve nodes. Thus, in combination with a data volume having the redundancy of 2 or higher, the database can be automatically restarted after a node failure. A typical database is configured with the same active nodes as its data volume to ensure data locality. After a volume node failure (and despite any succeeding automatic database restart), the data volume loses the redundancy of one node. Explanation To automatically recover a missing data redundancy in the above-mentioned scenario, a process exists to handle this situation. For this process to work, the user is required to define a Restore Delay in the database configuration, whose default value is 10 minutes, which means Look at all database and volume nodes 10 minutes after an automatic database restart and try to move data from the offline volume node to the newly utilized database reserve node. Due to the nature of a data move operation (it is very expensive), this operation should be prevented, if possible. Thus, this process only moves data under the following circumstances: the timeout of the restore delay after a database startup has been reached: In the case of multiple database restarts, e.g. due to hardware failures, do not start data move operations too early. the database has been restarted automatically: If a database has been started manually, the current configuration is accepted as is. exactly one volume node is offline: If all volume nodes are online, the database nodes should be moved instead to match the volume nodes (this requires a user-triggered database restart). If more than one volume node is offline, the operation will not be started, either (and a monitoring error message will be logged). data can be accessed locally by database after moving data: If data from the offline volume node can only be moved to a database node, which is not responsible for the management of the appropriate volume node data, the operation will not be started, either (and a monitoring error message will be logged).
View full article
This article describes the difference between local and global joins, and how to convert them. 
View full article
This article describes a few approaches to dealing with multi-tenancy databases
View full article