Itgendch637: De combinatie van tabelnaam 'DOCUMENTATTACHMENTFILESBULK', partitienaam '' en datacontaineralias '' moet ten minste één geregistreerde tabelpartitie selecteren om te vernieuwen

Bij het uitvoeren van de volgende opdrachten krijg de foutmelding zoals te zien in het onderwerp en in het screenshot hieronder:
use 1234567

alter persistent cache table transactionlinesincremental force refresh approach copy

alter persistent cache table documentattachmentfilesbulk force refresh approach copy

Nog wel vermeld dient te worden dat het ophalen van de transactionlinesincremental wel probleemloos is verlopen. Het ophalen van de documentattachmentfielsbulk geeft wel deze foutmelding.

Hoe kan ik dit oplossen?

image

Is er wellicht een statusupdate beschikbaar?

Het lijkt er op dat het initieel laden van de DocumentAttachmentFilesBulk uit Exact Online niet gebeurd is; zie foutmelding tekst.

Is de tabel mogelijk verwijderd (alter persistent cache drop ...) verwijderd uit Data Replicator of is het een nieuwe Data Replicator omgeving?

Het initieel laden kan bijvoorbeeld getriggerd worden met:

use all@eol

select count(*) from documentattachmentfilesbulk

Dit kan enige tijd duren. Controleer na afloop dat in de SQL Server view dc_table_partitions_r voor elke partitie waar nodig de tabel DocumentAttachmentFilesBulk een rij staat.

Daarna hoort het refresh-verzoek wel te slagen.

Afgelopen vrijdagmiddag heb ik de volgende opdrachten uitgevoerd, doordat deze te lang liepen heb ik deze rond 20:50 uur gecancelled.

use all@eol

select count(*) from documentattachmentfilesbulk

Vanochtend heb ik dezelfde opdrachten opnieuw gestart.
Dit loopt echter gierend uit de klauwen…
De beschikbare schijfruimte loopt per minuut terug.
Opnieuw heb ik zojuist het proces gecancelled omdat de beschikbare ruimte met de minuut slinkt.

Hoe kan ik de benodigde tabellen binnen de normale proporties houden?

De mdf-file van SQL Server heeft hier een omvang van 1,1 TB. Dat is erg veel. Het is niet te zien waar dit door veroorzaakt wordt. De omvang van DocumentAttachmentFilesBulk kan enorm zijn; het gaat om de binaire representatie van alle documentbijlages in alle administraties.

Wat is de verwachte omvang?

Wat zijn de grootste administraties en tabellen volgens de view dc_table_partition_versions_r?

De omvang van de documentbijlagen is ook in enkele minuten te schatten met de volgende query:

select Division
,      round(4 * 1.25 * FileSize / 1e9, 1) GB
from   ( select /*+ ods(false) */ 
                Division
         ,      sum(FileSize) FileSize
         from   DocumentAttachmentsIncremental@eol
         group
         by     Division
       )

Hierbij staat 4 voor het maximaal aantal geladen versies, inclusief opruimfase en 1.25 voor de overhead van free space in de database en indexen.

Een test op een financiële administratie met 40.000 documenten en 300.000 boekstukregels gaf circa 45 GB aan opslagbehoefte voor de documentbijlagen.

Hou er rekening mee dat de Invantive SQL-engine naast de inhoud van de database ook de documentbijlagen zelf als cache bewaart; doordat de echte documentbijlagen onwijzigbaar zijn is het mogelijk ze op disk te bewaren en opnieuw te gebruiken indien er om gevraagd wordt. Dit zou in de aangehaalde test circa 10 GB aan diskstorage vragen.

Een alternatief is om specifiek voor deze documentbijlage geen Data Replicator te gebruiken; het betreft een vrijwel statistische dataset van grote omvang waar hoogstens documenten bij komen en soms verdwijnen. Als de DocumentsAttachmentsIncremental gerepliceerd wordt (wat heel snel werkt), dan kunnen de BLOB’s naar schijf geschreven worden buiten de SQL Server database.

punt voor punt wil ik dit advies natuurlijk graag afhandelen:

  1. wat is de verwachte omvang van DocumentAttachmentFilesBulk?
    Deze vraag zou ik moeten kunnen beantwoorden door het uitvoeren van de genoemde zaken:
    Wat zijn de grootste administraties en tabellen volgens de view dc_table_partition_versions_r?
    Mijn tegenvraag hierop is: Welke query moet ik daarvoor gebruiken?
    Als ik hierop zou vooruit lopen, dan zou ik de query uitvoeren met genoemd resultaat als gevolg in onderstaand screenshot:
  2. het schatten van de omvang van de documentbijlagen (m.b.v. de door genoemde query uitgevoerd in de querytool levert onderstaand screenshot op:
    image

kortom 1): ik kan daar zinnige info uit krijgen, behalve dan de volgende:
er wordt een opvraging gedaan op de tabel DocumentAttachmentsIncremental terwijl ik niet eens wist dat die bestond. Daarnaast levert die maar voor 1 administratie resultaten op, terwijl ik voor bijna 40 administraties resultaten zou verwachten.

Kortom 2): wat moet er nu gebeuren?

Deze query geeft per administratie het maximum van de documentbijlagen aan:

select ptn_name
,      count(distinct tpn_version) version_cnt
,      max(tpn_count_rows) tpn_count_rows
,      max(round(tpn_estimated_size_characters/1e6, 0)) tpn_estimated_size_mb
from   dc_table_partition_versions_r
where  tbe_full_qualified_name = 'ExactOnlineREST.Documents.DocumentAttachmentFilesBulk'
and    tpn_state != 'D'
group
by     ptn_name
order
by     tpn_estimated_size_mb desc

Een schatting voor het geheel kan dan met:

select sum(4 * 1.25 * tpn_estimated_size_mb)
from   ( select ptn_name
         ,      count(distinct tpn_version) version_cnt
         ,      max(tpn_count_rows) tpn_count_rows
         ,      max(round(tpn_estimated_size_characters/1e6, 0)) tpn_estimated_size_mb
         from   dc_table_partition_versions_r
         where  tbe_full_qualified_name = 'ExactOnlineREST.Documents.DocumentAttachmentFilesBulk'
         and    tpn_state != 'D'
         group
         by     ptn_name
       ) t

De geschatte maximale omvang is 329 GB.

De feiten worden opgeslagen in de facts table:

select distinct tbe_facts_table_name
from   dc_table_partition_versions_r
where  tbe_full_qualified_name = 'ExactOnlineREST.Documents.DocumentAttachmentFilesBulk'
and    tpn_state != 'D'

Zijnde dcd_nmr4a. In de Top Tables staat die voor 929 GB en 1 GB indexes met vrijwel geen Unused space, verspreid over 8,2 miljoen rijen:

Disk space table

De verwachting is echter 2,3 miljoen documenten,bepaalde met de volgende query:

select sum(4 * tpn_count_rows)
from   ( select ptn_name
         ,      count(distinct tpn_version) version_cnt
         ,      max(tpn_count_rows) tpn_count_rows
         ,      max(round(tpn_estimated_size_characters/1e6, 0)) tpn_estimated_size_mb
         from   dc_table_partition_versions_r
         where  tbe_full_qualified_name = 'ExactOnlineREST.Documents.DocumentAttachmentFilesBulk'
         and    tpn_state != 'D'
         group
         by     ptn_name
       ) t

We selecteren een administratie 1246933 met 10.671 documenten / 926 MB volgens Data Replicator, gemiddeld elk <100 KB. De volgende query geeft aan dat er inderdaad 10.671 documenten in de Data Replicator versie staan:

select count(*) 
from   dcd_nmr4a
where  tpn_id$ = 646561

De omvang van deze 10.671 klopt ongeveer:

select sum(Datalength(ddfb76cf6a2fac5e043ef62984f0b1) )/1e6
from   dcd_nmr4a
where  tpn_id$ = 646561

waar voor de documenten alleen al 789 MB uitkomt. De totale omvang is dan pakweg 800 MB, en dat is redelijk in de buurt van geschatte 926 MB volgens Data Replicator.

Vervolgens maken we een analyze per tabelpartitieversie met:

select tpn_id$
,      sum(Datalength(ddfb76cf6a2fac5e043ef62984f0b1)) size_b
,      count(*) cnt
into   tmp_partition_sizes
from   dcd_nmr4a
--where  tpn_id$ = 646561
group
by     tpn_id$

Hier komt een tabel tmp_partition_sizes uit met per combinatie van administratie en versie van de data de omvang in bytes en het aantal documenten. Dit duurde nog geen minuut.

De volgende query correleert de inhoud van de database met het repository qua aantal rijen en aantal MB:

select coalesce(tpndisk.tpn_id$, tpndr.tpn_id) tpn_id
,      case
       when tpndisk.tpn_id$ is not null 
	   then 'X'
	   else '-'
	   end
	   + case 
	     when tpndr.tpn_id is not null 
	     then 'X'
		 else '-'
		 end
       category
,      round(tpndisk.size_b / 1e6, 0) disk_size_mb
,      round(tpndr.tpn_estimated_size_characters / 1e6, 0) repository_size_mb
,      tpndisk.cnt
,      tpndr.tpn_count_rows
from   tmp_partition_sizes tpndisk
full
outer
join   ( select *
         from   dc_table_partition_versions_r tpndr 
		 where  tpndr.tbe_full_qualified_name = 'ExactOnlineREST.Documents.DocumentAttachmentFilesBulk' 
		 and    tpndr.tpn_state != 'D' 
	   ) tpndr
on     tpndr.tpn_id = tpndisk.tpn_id$

Hier blijkt uit dat er veel tabelpartitieversies in de database staan die niet meer in het repository staan. De meest recente daarvan is van pakweg 28 oktober en enkele honderden zijn ouder. Deze tabelpartitieversies zijn niet terug te vinden in het repository bij dc_table_partition_versions.

In de event logging is nog 1 rij terug te vinden over de meest recente overbodige tabelpartitieversie:

select *
from   dc_event_log
where  tpn_id=616104

itgendch193
Dropped table partition version ‘616.104 - Obsoleted v764 (table 76 - ExactOnlineREST.Documents.DocumentAttachmentFilesBulk, partition 69 - 2274689)’.
2021-11-05 14:42:23.497
Deleted no rows from facts table dcd_nmr4a since the MD5 hash is empty (ExactOnlineREST.Documents.DocumentAttachmentFilesBulk).
Free field 1: O
Free field 2: D
Free field 3: itgendch726

Hieruit volgt dat het verwijderen niet gedaan is omdat er volgens het repository geen gegevens waren geladen, zoals normaliter gesignaleerd wordt door de MD5 hash.

Het volgende statement maakt een lijst van op te ruimen tabelpartitieversies:

--
-- Create list of table partition version IDs to purge.
--
select distinct 
       tpn_id$
into   tmp_tpn_to_purge
from   dcd_nmr4a
where  tpn_id$ 
       not in 
       ( select id
         from   dc_table_partition_versions
       )

Het opruimen kan vervolgens in batches van 10.000 (ongeveer 1 GB aan documentbijlagen) met code zoals:

declare 
  @cnt int = 1;
begin
  while @cnt != 0
  begin
    delete top(1000)
    from   dcd_nmr4a
    where  tpn_id$ in ( select tpn_id$ from tmp_tpn_to_purge )
	;
	set @cnt = @@rowcount;
	print @cnt;
  end;
end;

Het blijkt dat bij een zestal tabellen de table_md5, history_table_md5 en lv_overall_view_md5 leeg zijn, maar dat de tabellen wel bestaan. Bij DocumentAttachmentFilesBulk zijn deze kolommen wel gevuld, maar uit de itgendch726-melding blijkt dat dat rond 5 november niet het geval was. In die periode waren er ook veel verstoringen bij het ophalen van data uit Exact Online.

De data is gerepareerd met:

update dc_tables
set    table_md5 = 'iets'
where  table_md5 is null

update dc_tables
set    history_table_md5 = 'iets'
where  history_table_md5 is null

update dc_tables
set    lv_overall_view_md5 = 'iets'
where  lv_overall_view_md5 is null

Na het schonen is het advies om de tabel te herbouwen; hierdoor zal teruggaan naar pakweg 300 GB.

Zekerheidshalve zal de volgende release 20.2.150 een aantal extra controles bevatten waardoor laden vroegtijdig faalt indien de table_md5 voor welke reden dan ook leeg is.

Het downloaden van de grote aantal documentbijlagen kan ook omgezet worden naar een incrementele benadering:

use all@eol

create table settings@sqlserver
as
select 1 timestampmax

declare
  l_timestamp          integer;
  l_timestamp_next_min integer;
  g_step_size          pls_integer := 10000;
begin
  select /*+ low_cost */ timestampmax 
  into   l_timestamp
  from   settings@sqlserver
  ;
  l_timestamp_next_min := l_timestamp + g_step_size;
  for in
  ( select /*+ ods(false) http_disk_cache(false) http_memory_cache(false) */ 
           sdt.document
    ,      sdt.url
    ,      sdt.timestamp
    from   SyncDocumentAttachments@eol sdt
    join   AttachmentByUrl@eol(sdt.url) atl
    where  sdt.timestamp > l_timestamp
    and    sdt.timestamp < l_timestamp_next_min
  )
  loop
    if r.timestamp > l_timestamp
    then 
      l_timestamp := r.timestamp;
    end if;
    -- Schrijf weg naar disk.
  end loop;
  --
  if l_timestamp < l_timestamp_next_min
  then
    l_timestamp := l_timestamp_next_min;
  end if;
  --
  update settings@sqlserver
  set    timestampmax = l_timestamp
  ;
end;

Het opruimen in batches van 10.000 documentbijlagen was na zo’n 5 en een half uur klaar.

De andere opruimopdracht was klaar binnen de 4 uur.

Een bericht is gesplitst naar een nieuw topic: Itgencmr088 itgencmr088