Hi Tim,

sorry for not sending this part to the list:

two examples:


delete from ACCOUNT_UPDATE where ID_ACCOUNT = 123 and CDATE_BOOKED < '2018-03-05 12:19:00.000';
(uses an index on ID_ACCOUNT + CDATE_BOOKED)

Hendrik Woltersdorf

FinTech Group AG
Peter-Breuer-Str. 13
08056 Zwickau

FinTech Group AG, Frankfurt am Main - HRB Frankfurt 103516 - Gerichtsstand Frankfurt am Main - Vorstand: Frank Niehage (Vors.), Muhamad Said Chahrour - Aufsichtsratsvorsitzender: Martin Korbmacher - www.fintechgroup.com 
Diese E-Mail enthält vertrauliche oder rechtlich geschützte Informationen und ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, informieren Sie bitte sofort den Absender und löschen diese E-Mail. Bitte beachten Sie, dass jede Form der Veröffentlichung, Vervielfältigung oder Weitergabe des Inhaltes dieser E-Mail unzulässig und nicht gestattet ist. Verfälschungen des ursprünglichen Inhaltes dieser Nachricht bei der Datenübertragung können nicht ausgeschlossen werden. E-Mails können manipuliert werden und Viren oder ähnliche Sicherheitsrisiken enthalten.
This e-mail contains confidential or legally protected information and is exclusively meant for the named addressee. In case you are not the intended addressee of this e-mail or its representative please inform the sender immediately and delete the e-mail. Please note that every form of publication, duplication or propagation of the content of this e-mail is forbidden and not allowed. Falsification of the original content of this message during the data transfer cannot be excluded. Furthermore, e-mails may contain viruses or similar security risks.

Inactive hide details for Tom Egan ---05.03.2018 14:11:13---Can you share the sql? Sent from my iPhoneTom Egan ---05.03.2018 14:11:13---Can you share the sql? Sent from my iPhone

Von: Tom Egan <tomegan@bellsouth.net>
An: Mauritz Sundell <mauritz.sundell@oracle.com>
Kopie: Hendrik Woltersdorf <hendrik.woltersdorf@xcom.de>, cluster@lists.mysql.com
Datum: 05.03.2018 14:11
Betreff: Re: Out of operation records in local data manager far below MaxNoOfConcurrentOperations

Can you share the sql?

Sent from my iPhone

> On Mar 5, 2018, at 4:24 AM, Mauritz Sundell <mauritz.sundell@oracle.com> wrote:
> Hi Hendrik
>> On 2018-03-05 09:03, Hendrik Woltersdorf wrote:
>> Hi,
>> we run a MySQL-Cluster, currently version 7.4.15, where we get "Out of
>> operation records in local data manager" at approximately 55000 rows
>> updated or deleted in one transaction,
>> even though MaxNoOfConcurrentOperations=300000.
>> Any ideas, why 300000 operation records are not enough for 55000 rows?
> Assuming there are no other concurrent transactions, this could be due to extra implied load such as:
> 1) changes to unique indexes, each change takes an operation.
> 2) changes to blob columns, each change column can take one or more operation depending  on size of value.
> 3) foreign keys causing lookups in parent table
> 4) foreign keys cascading into child tables
> Or it could be due to skew load due to:
> 5) Partial primary key used as partitioning key.
> 6) The number of partitions do not match number of LDM-threads.
>     This should typically not happen unless explicitly expressed, or if one have reconfigured cluster with more LDM-threads or adding nodes without runnning reorganize partitions.
> One can also configure the number of operations records in local data manager (LDM) with MaxNoOfLocalOperations.
> By default that is slightly bigger than MaxNoOfConcurrentOperation.
> Mauritz
> --
> MySQL Cluster Mailing List
> For list archives:
> To unsubscribe: