Skip to Content
Product Information

TDF: Otimizando o consumo de memória com particionamento e NSE

 

 

No blog post Otimização do consumo de memória e armazenamento de dados em sistemas TDF, falamos sobre como funciona a Native Storage Extension e sobre como você pode se beneficiar deste recurso para reduzir o consumo de memória do TDF.

Também publicamos o blog post TDF: Dicas para otimizar o consumo de memória, que ajuda você a fazer uma faxina nos objetos não utilizados e com isso prepara o terreno pra usar o NSE.

Então, hoje, vamos dar sequência no assunto sobre NSE. O objetivo deste blog post é mostrar quais tabelas o time de desenvolvimento do TDF identificou como possível reduzir o consumo de memória utilizando o particionamento por RANGE e o NSE.

A recomendação descrita neste blog post é válida apenas para o cenário de instalação do TDF Add-on com SAP Landscape Transformation (SLT).

 

Particionamento das tabelas do TDF

 

Como o TDF tem a característica de utilizar com maior frequência os dados dos últimos dois anos, podemos utilizar o NSE em conjunto com o particionamento movendo as partições mais antigas e menos usadas para o NSE.

Mover as partições antigas para o NSE é o mesmo que dizer ao HANA “Essas partições são raramente acessadas, não precisa mantê-las carregadas em memória”.

Na análise das tabelas utilizadas pelo TDF, verificamos que as tabelas BSEG e FAGLFLEXA são as que trazem maiores ganhos de memória com a utilização do particionamento, então vamos mostrar como particionar as tabelas BSEG e FAGLFLEXA por RANGE, de modo que o HANA consiga fazer o partition pruning, ou seja, evitar o carregamento das partições em memórias que não foram solicitadas pela aplicação. Isso reduzirá o consumo de memória e também vai melhorar a performance das consultas.

Vale lembrar que essa é uma recomendação para o TDF standard. Se você possui soluções adicionais de parceiros ou customizações, precisará ter o cuidado adicional de verificar se essa solução se comporta da mesma forma que o TDF.

Utilizaremos a forma de particionamento single level RANGE HETEROGENEOUS. Hoje, o NSE suporta apenas as formas de particionamento RANGE e RANGE-RANGE.

A dica para escolher um bom RANGE é deixar os registros mais antigos agrupados em uma mesma partição (sem passar o limite de 2 bilhões). Isso evita o excesso de partições, bem como deixar uma partição do tipo others caso algum registro não se encaixe na sua definição de RANGE. Esse tipo de particionamento requer uma maior governança, já que precisará ser atualizado de tempos em tempos. Considerações antes de particionar as tabelas:

  • Pausar a replicação via SLT antes de iniciar o procedimento, retomar após concluído
  • Esteja preparado para um downtime de horas dependendo do seu volume de dados
  • Tenha um excedente de memória em disco, já que o HANA gera logs para poder reverter a operação de particionamento em caso de falha
  • Tenha um excedente de memória RAM, pois o HANA vai utilizar mais memória durante o particionamento

Exemplo de select para contar os registros por ano, para auxiliá-lo na escolha de um bom RANGE:

select RYEAR, count(*) FROM "YOUR_SCHEMA"."FAGLFLEXA"

GROUP BY RYEAR;

O comando de exemplo a seguir é um guia. Nele, você precisará definir quais são os melhores valores para o seu RANGE de acordo com os dados existentes na sua base.

Exemplo de particionamento da FAGLFLEXA utilizando o campo RYEAR.

ALTER TABLE "YOUR_SCHEMA"."FAGLFLEXA" PARTITION BY RANGE (RYEAR)

   ((PARTITION '0000' <= VALUES < '2018'),

    (PARTITION '2018' <= VALUES < '2019'),

    (PARTITION '2019' <= VALUES < '2020'),

    (PARTITION '2020' <= VALUES < '2021'),

    (PARTITION OTHERS));

 

Agora, vamos mover as partições mais antigas para o NSE, deixando apenas os dois últimos anos fora do NSE. Modifique os comandos abaixo de acordo com o seu cenário.

ALTER TABLE "YOUR_SCHEMA"."FAGLFLEXA" ALTER PARTITION 1 PAGE LOADABLE;

ALTER TABLE "YOUR_SCHEMA"."FAGLFLEXA" ALTER PARTITION 2 PAGE LOADABLE;

ALTER TABLE "YOUR_SCHEMA"."FAGLFLEXA" ALTER PARTITION 3 PAGE LOADABLE;

 

Exemplo de particionamento da BSEG utilizando o com campo GJAHR.

ALTER TABLE "YOUR_SCHEMA"."BSEG" PARTITION BY RANGE (GJAHR)

   ((PARTITION '0000' <= VALUES < '2019'),

    (PARTITION '2019' <= VALUES < '2020'),

    (PARTITION '2020' <= VALUES < '2021'),

    (PARTITION OTHERS));

 

Movimentação das partições para o NSE.

ALTER TABLE "YOUR_SCHEMA"."BSEG" ALTER PARTITION 1 PAGE LOADABLE;

ALTER TABLE "YOUR_SCHEMA"."BSEG" ALTER PARTITION 2 PAGE LOADABLE;

 

Caso você encontre a mensagem de erro “Fail to alter column’s load unit: Column ID … is in an old persistent format. Please execute the Delta merge and re-execute the operation.”, a solução para isso está descrita na SAP Note 2927591.

Basicamente, você precisará apenas executar o comando abaixo:

select count(*) from <table_name> merge delta of <table_name> force rebuild;

Se, por outro lado, você encontrar a mensagem de erro “Feature not supported: modifying partition property for non-HETEROGENEOUS partitioned tables”, a solução se encontra na SAP Note 2915190.

 

Mais informações sobre particionamento e NSE.

SAP Note 2044468 – FAQ: SAP HANA Partitioning

SAP Note 2799997 – FAQ: SAP HANA Native Storage Extension (NSE)

 

Considerações finais

 

Vale lembrar que o ganho de performance e memória depende do tamanho da sua base de dados: se o seu volume de dados é pequeno, não recomendamos o particionamento pois neste caso, pode piorar a performance de execução. Utilizando o particionamento das tabelas do TDF em conjunto com o NSE, esperamos ajudar o seu hardware a suportar por mais tempo o crescimento da sua base.

Gostaríamos muito de saber o seu feedback. Deixe seu comentário abaixo caso tenha alguma dúvida ou sugestão para um próximo post.
Além dos comentários, você pode entrar em contato conosco através da plataformaCustomer Influence. Lá, você pode propor ideias para melhorar nosso produto, votar em outras ideias já lançadas e acompanhar ideias em implementação.
Também não se esqueça de seguir a tag SAP Tax Declaration Framework for Brazil aqui na SAP Community para ficar ligado nas últimas notícias sobre o TDF. 

Um abraço e até a próxima,

Carolina Hefler e Jovani Alves

Time de desenvolvimento TDF

_______________________________________________________________________________

 

TDF: Optimizing Memory Consumption with Partitioning and NSE

 

In the TDF: Optimization of memory consumption and data storage in TDF systems blog post, we discussed how Native Storage Extension works and how you could benefit from this resource to reduce TDF memory consumption.

We have also published the TDF: Tips to optimize memory consumption blog post. It helps you with the cleanup of unused objects and prepares for the use of NSE.

Today, we are continuing with the NSE topic. The aim of this blog post is to show which tables the TDF development team identified as prone to perform the reduction of memory consumption using RANGE partitioning and the NSE.

The recommendation we describe here is only valid for the TDF Add-on with SAP Landscape Transformation (SLT) installation scenario.

 

TDF table partitioning

 

TDF tends to use data from the last two years. Thus, we can use NSE with partitioning moving older and less used partitions to NSE.

Moving older partitions to NSE is the same as informing HANA that “these partitions are rarely accessed, so it is not necessary to keep them loaded in memory”.

On analyzing the tables used in TDF, we verified that the BSEG and the FAGLFLEXA tables are those that bring the biggest memory gain when using partitioning. As such, we will show you how to partition the BSEG and the FAGLFLEXA tables by RANGE, so that HANA manages to do the partition pruning. In other words, we show you how to prevent loading in memory partitions that were not requested by the application. This reduces memory consumption and improves query performance.

It is worth mentioning that this is a standard TDF recommendation. If you have additional partner solutions or customizations, extra care is needed to verify if this solution behaves the same way TDF does.

We will use single level RANGE HETEROGENEOUS partitioning. Today, NSE only supports RANGE and RANGE-RANGE partitioning forms.

A tip to select a good RANGE is to group old registers in a same partition (without crossing the 2 billion threshold). This prevents the excess of partitions and prevents leaving a partition of type others in case some register does not fit the RANGE definition. This kind of partition requires more governance, as it needs to be updated from time to time. Here are some things you should keep in mind before partitioning the tables:

  • Pause replication via SLT before starting the procedure, resuming it after the conclusion
  • Be ready for downtime for some hours, depending on the amount of data
  • Have exceeding memory in disk, as HANA generates logs to revert the operation if it fails
  • Have exceeding RAM memory, as HANA will use more memory during partitioning

Example of select to count registers per year to help you select a good RANGE:

select RYEAR, count(*) FROM "YOUR_SCHEMA"."FAGLFLEXA"

GROUP BY RYEAR;

The example command that follows is a guide. In it, you will need to define which are the best values for your RANGE according to the data that exists in your base.

Example of FAGLFLEXA partitioning using the RYEAR field:

ALTER TABLE "YOUR_SCHEMA"."FAGLFLEXA" PARTITION BY RANGE (RYEAR)

   ((PARTITION '0000' <= VALUES < '2018'),

    (PARTITION '2018' <= VALUES < '2019'),

    (PARTITION '2019' <= VALUES < '2020'),

    (PARTITION '2020' <= VALUES < '2021'),

    (PARTITION OTHERS));

Let us now move the older partitions to NSE, leaving only the last two years out of it. Modify the commands that follow according to your scenario.

ALTER TABLE "YOUR_SCHEMA"."FAGLFLEXA" ALTER PARTITION 1 PAGE LOADABLE;

ALTER TABLE "YOUR_SCHEMA"."FAGLFLEXA" ALTER PARTITION 2 PAGE LOADABLE;

ALTER TABLE "YOUR_SCHEMA"."FAGLFLEXA" ALTER PARTITION 3 PAGE LOADABLE;

 

Example of BSEG partitioning using the GJAHR field.

ALTER TABLE "YOUR_SCHEMA"."BSEG" PARTITION BY RANGE (GJAHR)

   ((PARTITION '0000' <= VALUES < '2019'),

    (PARTITION '2019' <= VALUES < '2020'),

    (PARTITION '2020' <= VALUES < '2021'),

    (PARTITION OTHERS));

 

Moving partitions to NSE

ALTER TABLE "YOUR_SCHEMA"."BSEG" ALTER PARTITION 1 PAGE LOADABLE;

ALTER TABLE "YOUR_SCHEMA"."BSEG" ALTER PARTITION 2 PAGE LOADABLE;

 

If you find an error message saying “Fail to alter column’s load unit: Column ID … is in an old persistent format. Please execute the Delta merge and re-execute the operation.”, the solution for it is described on SAP Note 2927591.

You will only need to execute the following command:

select count(*) from <table_name> merge delta of <table_name> force rebuild;

On the other hand, if you find an error message saying “Feature not supported: modifying partition property for non-HETEROGENEOUS partitioned tables”, the solution for it is on SAP Note 2915190.

 

More information on partitioning and NSE?

SAP Note 2044468 – FAQ: SAP HANA Partitioning

SAP Note 2799997 – FAQ: SAP HANA Native Storage Extension (NSE)

 

Final thoughts

 

Note that the gain in performance and memory depends on the size of your database; if the amount of data is small, we do not recommend partitioning as it can make performance worse. Using TDF table partitioning with NSE we hope to help your hardware support the growing of your database for a longer period.

 

We would love to have your feedback. If you have any question or suggestion for an upcoming post, please leave your comment below.  

Apart from the comment section, you can also contact us through the Customer Influence platform, where you can propose ideas to improve our product, vote on previously released ideas and follow those ideas being currently implemented.  

Follow the SAP Tax Declaration Framework for Brazil tag here at the SAP Community to keep updated with the latest news on the TDF Add-On.  

See you next time. 

Best regards,
Carolina Hefler and Jovani Alves
TDF Development Team 

 

 

 

/
Be the first to leave a comment
You must be Logged on to comment or reply to a post.