[Exact] Database groeit vrij snel

[Trommelrem]

Bij een klant van mij draait Exact. De database was in 2012 zo'n 8 GB groot. Nu is de database maarliefst 35 GB groot. De groei sinds 2012 is veel sneller dan daarvoor. Exact zegt dat dit meestal normaal is, maar dat ze wel een engineer kunnen langs sturen om het te onderzoeken. Gebruikers klagen over traagheid. De oorzaak van de traagheid ga ik los hiervan onderzoeken. Dit hoeft immers niet aan de 35 GB te liggen.

Uiteraard heb ik de database al gecompressed en de Exact tools al gedraaid. De database blijft 35 GB en de logbestanden worden netjes geflushed bij iedere full backup.

Ik kan dus een Exact engineer inhuren. Echter dat is vrij kostbaar en uiteraard is er dus de kans dat hij aantoont dat 35 GB normaal is. Daarom zou ik graag van iemand hier willen horen of 35 GB normaal is voordat ik een engineer laat langskomen. Het is een klein bedrijf met slechts 8 werknemers die in Exact werken. Er staan geen tienduizenden producten in Exact. Het bedrijf is niet heel erg gegroeid in de afgelopen 2 jaar. Wel hebben ze 20 Exact modules, dus volgens Exact zou de database daarom erg groot zijn.

Wie heeft er ervaring met Exact en kan mij vertellen of 35 GB normaal is voor een klein bedrijf met 8 medewerkers die in Exact werken?

[Breezers]

@Trommelrem, heb je nog wat extra informatie ?

• Versie van SQL server ?
• Welke versie van Globe ?
• Hoeveel schijfruimte heb je nog over ?
• Type server, geheugen, aantal cores toegewezen ?
• Database en log groei staan nog op 10% unrestricted ?
• Betreft het hier Exact Globe Next alleen of zit hier ook bijv. Exact Synergy Enterprise bij ?
• Hoeveel verschillende administraties heeft deze dit bedrijf ? (aantal DB's)
• Hoe oud zijn de administraties en is er in het verleden geupgrade van bijv 2000 of DOS ?
• Draaien er nog andere SQL applicaties, websites, maatwerk etc?
• Welke modulen staan actief ?(CRM verdubbeld namelijk je storage)
• Veel XML imports en/of opslaan documenten/facturen ?
• XML logboek geeft fouten ?
• Enig idee van welke tabellen de meeste data bevatten of groei hebben ?(GBKMUT, Amutas, BacoDiscussions, BLOBS, etc ?)
• Document opslag htm of pdf ? (BLOBS, PDF documents settings ?)
• Weet je zeker dat je maintenance plan correct staat ingesteld ?

Het gaat niet echt om het aantal gebruikers/medewerkers, maar natuurlijk aantal transacties per dag en mutaties etc. Maar 35 GB voor louter een enkele Globe DB als administratie is redelijk groot, ik ken bedrijven die 80 gebruikers hebben en meerdere administraties, waarbij de grootste administratie 16-17 GB is met veel mutaties.

Database compressie wordt zo ver ik weet altijd afgeraden.....
Performance is meestal te wijten aan geheugen en de locaties waar de DB's staan opgeslagen

Uiteraard schiet ik hier even uit de heup, aangezien ik niet de variabelen weet ? Anders wordt je vraag er een in de trend van "Ik heb een auto die rijd 1:7, vraag: is dit normaal ?" zonder aan te geven wat voor auto

[ Voor 22% gewijzigd door Breezers op 08-12-2014 06:53 ]

[F_J_K]

CSA ==> SWS

[Trommelrem]

Excuses, ik had deze informatie inderdaad moeten vermelden:

• Versie van SQL server ?
SQL 2008 R2 SP1 Standard edition.
Upgrade naar SP3 staat ingepland, maar is nog niet uitgevoerd .

• Welke versie van Globe ?
Versie 408

• Hoeveel schijfruimte heb je nog over ?
10 GB. Daarbij moet ik vermelden dat er tijdelijk een kopie is van de database. Die is dus ok 35 GB. Normaliter zou er 45 GB vrij moeten zijn.

• Type server, geheugen, aantal cores toegewezen ?
8 cores, 8 GB.
Cores zijn dedicated en dus niet gedeeld met andere VM's. Geheugen staat vast en is dus niet dynamic. De SQL heeft dedicated disks voor z'n MDF files. Gewoon vhdx, niet passthrough.

• Database en log groei staan nog op 10% unrestricted ?
Ja.

• Betreft het hier Exact Globe Next alleen of zit hier ook bijv. Exact Synergy Enterprise bij ?
Alleen Globe Next.

• Hoeveel verschillende administraties heeft deze dit bedrijf ? (aantal DB's)
2, één productiedatabase en af en toe wordt de productiedatabase gekopieerd naar een testdatabase. De testdatabase wordt bijna nooit gebruikt.

• Hoe oud zijn de administraties en is er in het verleden geupgrade van bijv 2000 of DOS ?
Die informatie probeerde ik al te achterhalen, maar ik weet het eigenlijk niet. De database staat op SQL 2008 (100) mode en simple recovery. Ik was er wel bij toen de upgrade van 2003 naar 2008 R2 plaatsvond. Het betreft een SBS 2011 omgeving die uit een 2003 omgeving komt. Er is geen swing migratie geweest, alles is opnieuw geinstalleerd. Wel vermoed ik dat de database is begonnen in het Pre-2003 tijdperk.

• Draaien er nog andere SQL applicaties, websites, maatwerk etc?
Ja. Er draait een SPFI pakket: www.spfi.nl

• Welke modulen staan actief ?(CRM verdubbeld namelijk je storage)
Bedoel je SE1800 E-CRM? Die staat inderdaad op actief.

• Veel XML imports en/of opslaan documenten/facturen ?
Weet ik eigenlijk niet. Zal het navragen bij de klant.

• XML logboek geeft fouten ?
Waar vind ik dat eigenlijk?

• Enig idee van welke tabellen de meeste data bevatten of groei hebben ?(GBKMUT, Amutas, BacoDiscussions, BLOBS, etc ?)
Weet ik eigenlijk niet.

• Document opslag htm of pdf ? (BLOBS, PDF documents settings ?)
Weet ik ook niet.

• Weet je zeker dat je maintenance plan correct staat ingesteld ?
Geen maintenance plan. Gebeurt handmatig.

Het gaat niet echt om het aantal gebruikers/medewerkers, maar natuurlijk aantal transacties per dag en mutaties etc. Maar 35 GB voor louter een enkele Globe DB als administratie is redelijk groot, ik ken bedrijven die 80 gebruikers hebben en meerdere administraties, waarbij de grootste administratie 16-17 GB is met veel mutaties.

Het zou door die CRM module dus kunnen dat de DB twee keer zo groot is. Als je wilt dan kan ik alle modules opsommen, als je er iets aan hebt.

Database compressie wordt zo ver ik weet altijd afgeraden.....
Performance is meestal te wijten aan geheugen en de locaties waar de DB's staan opgeslagen

Excuses, ik bedoel dat de database af en toe wordt geschrinked

Uiteraard schiet ik hier even uit de heup, aangezien ik niet de variabelen weet ? Anders wordt je vraag er een in de trend van "Ik heb een auto die rijd 1:7, vraag: is dit normaal ?" zonder aan te geven wat voor auto

Ik snap het. Mijn SQL kennis is eigenlijk 0,0 en van Exact weet ik eigenlijk alleen hoe je werkstations installeert. Een serverinstallatie kan ik alleen met de Exact documentatie erbij. Maar echt troubleshooten kan ik niet.

Dat van die CRM module is wel interessante info. Want een DB van 16 GB zou ik wel normaal vinden en dat verklaart direct waarom de DB 35 GB groot is.

[Breezers]

Heb je de ESI tool al eens gebruikt ?

Zo op het eerste gezicht zou ik denken dat de koppeling van SPFI een EDI koppeling is ?
Dan zou ik kunnen voorstellen dat er veel requesten en documenten worden opgeslagen (mogelijk zelfs dubbel en als PDF oid). Een standaard EDI koppeling doet ongeveer 11 van deze requesten en documenten per handeling, wat behoorlijk kan oplopen. Check eens welke tabellen er groot zijn met de ESI tool, met name de tabellen GBKMUT, Amutas, BacoDiscussions, BLobs)

XML is een recht dat een administrator kan toekennen en dan kan je in Globe onder het tabblad XML ook de XML logs zien. Als er veel logs zijn (al dan niet goedgekeurd/afgekeurd), dan kan het best zijn dat deze tabellen snel groeien.

CRM voegt in principe veel lege tabellen toe met cellen die gevuld zijn (NULL), hierdoor zal de database altijd groter zijn, echter dan zou die data ook gevuld moeten worden (handmatig of koppelingen), hierdoor zou ik eerder denken aan documenten en koppeling requesten die groeien (tenzij er veel handmatig entrys zijn door verkopers, marketing etc)

Het werkgeheugen en beschikbare ruimte vindt ik wel aan de magere kant, ook al gebeurt er niet heel veel.
Je kan/gaat tegen het scenario aanlopen dat er niet voldoende werkgeheugen is, hierdoor wordt dan een paging file gebruikt op je harde schijfruimte en kan al snel een bottleneck worden ivm performance ?

Geen idee hoe jij je backups maakt, maar na elke backup worden de logfile verwijdert, hierdoor gaan deze ook niet meer groeien en heb je ook veel meer schijfruimte nodig ?

Meestal zie je dat het gebruikelijk is om bij een update van Globe 2000 een nieuwe database aan te maken en daar in verder te gaan ipv migreren/conversie, maar aangezien het probleem rond 2012 is begonnen, neem ik niet aan dat dit er iets mee te maken kan hebben.

In Globe kan je aangeven in welk format documenten opgeslagen moeten worden, als je veel documenten genereert (bijv. met een EDI koppeling), dan kan je behoorlijk wat data opslaan (tevens als je niet de Exact PDF generator gebruikt) Vaak zie ik dan dat opslaan als .hmt wordt gebruikt, wat minder data geeft en documenten zijn dan later alsnog te printen via een PDF printer.Documenten Globe

[P_de_B]

Met onderstaand script kun je bekijken hoeveel ruimte iedere tabel inneemt:

SQL:

SELECT 
    t.NAME AS TableName,
    s.Name AS SchemaName,
    p.rows AS RowCounts,
    SUM(a.total_pages) * 8 AS TotalSpaceKB, 
    SUM(a.used_pages) * 8 AS UsedSpaceKB, 
    (SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM 
    sys.tables t
INNER JOIN      
    sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN 
    sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
INNER JOIN 
    sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN 
    sys.schemas s ON t.schema_id = s.schema_id
WHERE 
    t.NAME NOT LIKE 'dt%' 
    AND t.is_ms_shipped = 0
    AND i.OBJECT_ID > 255 
GROUP BY 
    t.Name, s.Name, p.Rows
ORDER BY 
    t.Name

Welke tabel(len) nemen veel ruimte in?

[Trommelrem]

Breezers schreef op dinsdag 09 december 2014 @ 12:43:
Heb je de ESI tool al eens gebruikt ?

ESI tool heb ik een jaar geleden gebruikt. Daar zijn geen issues uit gekomen. Ik zal de tool dit weekend weer draaien, wellicht zijn er issues gekomen die er toen niet waren.

Zo op het eerste gezicht zou ik denken dat de koppeling van SPFI een EDI koppeling is ?
Dan zou ik kunnen voorstellen dat er veel requesten en documenten worden opgeslagen (mogelijk zelfs dubbel en als PDF oid). Een standaard EDI koppeling doet ongeveer 11 van deze requesten en documenten per handeling, wat behoorlijk kan oplopen. Check eens welke tabellen er groot zijn met de ESI tool, met name de tabellen GBKMUT, Amutas, BacoDiscussions, BLobs)

SPFI is inderdaad een EDI koppeling. Verderop heb ik enkele tabelgroottes neergezet.

XML is een recht dat een administrator kan toekennen en dan kan je in Globe onder het tabblad XML ook de XML logs zien. Als er veel logs zijn (al dan niet goedgekeurd/afgekeurd), dan kan het best zijn dat deze tabellen snel groeien.

CRM voegt in principe veel lege tabellen toe met cellen die gevuld zijn (NULL), hierdoor zal de database altijd groter zijn, echter dan zou die data ook gevuld moeten worden (handmatig of koppelingen), hierdoor zou ik eerder denken aan documenten en koppeling requesten die groeien (tenzij er veel handmatig entrys zijn door verkopers, marketing etc)

Het werkgeheugen en beschikbare ruimte vindt ik wel aan de magere kant, ook al gebeurt er niet heel veel.
Je kan/gaat tegen het scenario aanlopen dat er niet voldoende werkgeheugen is, hierdoor wordt dan een paging file gebruikt op je harde schijfruimte en kan al snel een bottleneck worden ivm performance ?

Er komt een sales aan voor een nieuwe server. Vanwege de redelijk lage prijzen van MLC SSD's die door de HP/Dell controllers worden ondersteund, wordt de Exact database wellicht op een setje SSD's geplaatst. Omdat SSD's in een mirror vaak tegelijk stuk gaan voldoet een dagelijkse backup niet meer en zal ook een offsite Hyper-V replica worden ingezet naast de reguliere backups.

Voldoende geheugen zal ik op letten. Door de lage geheugenprijzen is het niet eens zo gek om net zo veel geheugen te nemen als de verwachte databasegrootte over 3 jaar.

Overigens, als ik naar de performance van de server kijk, dan zijn er inderdaad hard faults. De pagefile wordt dus daadwerkelijk gebruikt. Hard faults is in de buurt van nul, maar is helaas niet nul.

Geen idee hoe jij je backups maakt, maar na elke backup worden de logfile verwijdert, hierdoor gaan deze ook niet meer groeien en heb je ook veel meer schijfruimte nodig ?

Dagelijkse backup, simple recovery model, flush logs.

Meestal zie je dat het gebruikelijk is om bij een update van Globe 2000 een nieuwe database aan te maken en daar in verder te gaan ipv migreren/conversie, maar aangezien het probleem rond 2012 is begonnen, neem ik niet aan dat dit er iets mee te maken kan hebben.

De geschiedenis ken ik nog steeds niet precies, maar de eerste Exact Globe die ze gebruikten was op Windows Server 2003. Toen ik de omgeving overnam draaide men nog op SP1. Ik heb die omgeving een maand later naar Windows 2008 R2 met SQL 2008 R2 Standard gemigreerd.

In Globe kan je aangeven in welk format documenten opgeslagen moeten worden, als je veel documenten genereert (bijv. met een EDI koppeling), dan kan je behoorlijk wat data opslaan (tevens als je niet de Exact PDF generator gebruikt) Vaak zie ik dan dat opslaan als .hmt wordt gebruikt, wat minder data geeft en documenten zijn dan later alsnog te printen via een PDF printer.Documenten Globe

Ga ik na werktijd controleren.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[P_de_B]

De tabel met grootboekmutaties is dus heel groot. Worden administraties wel afgesloten en verdicht? Lastig om er echt definitief iets over te zeggen, maar het lijkt alsof er wel heel veel grootboekmutaties zijn voor een relatief klein bedrijf.

Daarnaast is de tabel BacoDiscussions en blobs vrij groot, dit zijn documenten die in Globe worden opgeslagen. Misschien afdrukken van facturen of zo? Daar is vrij weinig aan te doen, als die documenten in de database worden opgeslagen nemen ze ruimte in.

Voor de traagheid kan je exactpartner waarschijnlijk wel een query aanleveren die een aantal onderhoudstaken uitvoert (herindexeren, bijwerken statistieken etc).

[Trommelrem]

Zijn die grootboekmutaties eigenlijk de bankimports? Die functionaliteit hebben ze nog maar net een jaar.
Zijn alleen de blobs de documenten? Of ook de BacoDiscussions?

Bedankt trouwens voor de informatie. Ik heb straks een beter idee waarover ik precies praat als ik contact ga opnemen met Exact.

In de tussentijd heb ik het toegewezen geheugen van de SQL server verhoogd naar 12 GB. Maar een nieuwe server komt er deze zomer al aan. Ik ga nog eens goed met Exact doornemen wat hun vereisten precies zijn.