Arbeitsstop wegen Tabellocks

Hallo,

ich verfolge einige Diskusionen seit längerer Zeit mit regem Interesse, doch nun ist es an der Zeit selbst aktiv zu werden.

Ich bin Navisionbetreuer in einem mittelständichen Produktionsunternehmen, welches zwar schon seit über 2 Jahren Navision einsetzt, aber die Produktion sich erst im Aufbau befunden hat. Nun mit Produktionsstart und Hochlauf wird auch Navision mit Fertigungsaufträgen, Verbrauchsbuchungen, Lagerregulierungen und Umlagerungen succesive immer mehr belastet. Seit einigen Wochen steigt aber immer mehr der Unmut und Stimmen werden laut, dass Navision die Arbeit behindert statt unterstützt. Wir haben noch nicht mal die Hälfte der eigentlichen Produktionskapazität erreicht, aber das abschließen von Fertigungsaufträgen blockiert die Finanzbuchhaltung, Lagerreruglierungen blockieren Umalgerungen massiv, Umlagerungen im Lager blockieren Umlagerungen in der Produktion.

Ich gerate immer mehr unter Druck durch Anrufe durch die Produktionsleitung und die Kaufmännische Leitung, warum teilweise ganze Abteilungen immer häufiger und immer länger in Navision nicht arbeitsfähig sind.

Laut unserem Implementierungspartner ist dies auf Tabellocks zurück zu führen. Diese sind völlig normal und treten in jedem anderen Unternehmen auch so auf.

Ich kanns nur nicht mehr erkären wie ein ERP für eine halbe Millionen Euro (Summe inklusive Anpassungen und Schulung) für ein Unternehmen mit 10 Artikeln und einer Stückliste von 23 Komponenten und 9 Arbeitsgängen eine halbe Stunde lange Lagerregulierungen durchführen muss. Oder beim beenden von 4 Fertigungsaufträgen die FiBu eine halbe Stunde früher Feierabend machen muss, weil diese keine Rechnungen buchen kann.

Ich würde mich sehr über Erfahrungsberichte über andere Navisioninstallationen freuen, da ich sonst keine Vergleichsmöglichkeiten hab und nur auf die Aussagen des Implementierungspartners geb ich nichts mehr.

Grüße

PS: Weil ich denke das diese Frage aufkommen wird. Es gab schon einen Performancecheck der Hardware, Netzwerk und eine optimierung des MS-SQL-Servers. Alle Tests haben eine Ausreichende Performance bestätigt. Trotzdem wurde der Server mit noch mehr Arbeitsspeicher erweiter.

[fiddi]

Hallo Obsidian,

habt ihr schon an den Umstieg auf NAV 5.1 Sp1 Technik erwogen, bzw. ein Update auf NAV 5.1 oder 2009, dort ist die SQL-Server Unterstützung, wesentlich besser gelöst.

Gruß, Fiddi

Zuletzt geändert von fiddi am 1. Oktober 2009 12:10, insgesamt 2-mal geändert.

Hallo Obsidian,

zunächst ein "Herzlich Willkomen" hier im Forum

Bzgl. der Lagerregulierung, wie oft wird die durchgeführt?
(Evtl. könnte diese in der Nacht laufen?)

Wie ist der Server ausgerüstet (CPU / Speicher / HDDS´s), 32 oder 64 Bit-Rechner?
(Ist die Speicherverwendung evtl. nicht korrekt eingestellt (Stichworte: /PAE , /3GB, /AWE)

Leider kenne ich die Produktion nur aus der Version 3.7 auf einer Nativen DB. Hier war das Buchen der FA´s kein problem, -->wurde recht schnell gebucht und es wurde keiner blockiert.
Es wundert mich, das die FiBu blockiert wird (da eigentlich die Werte erst mit der Lagerregulierung "angefasst" werden?!). Mag auch sein das ich da nicht tief genug drin stecke.

Tablelocks:
Es ist richtig, das Tablelocks auftreten. Allerdings sollten diese (relativ) kurz sein. (Dieses soll ja beim verabeiten der Daten sicherstellen, das die Datensätze nicht von einem anderen User geändert werden)

Die Verabeitungsgeschwindigkeit hängt u.a. von folgenden Faktoren ab (gibt noch viele mehr):
- Auswahl der Keys
- Anzahl und konfiguraion der Key´s (z.B. wurde der Clustered Index gesetzt)
- Anzahl der Datensätze der jeweiligen Tabellen
- Verwendung von SQL-Optimierten C/AL Code (z.B. wenn die DB von einem Nativen Server aus 2.6 Zeiten kommt und der Code nicht Optimiert wurde)

Wenn in der Lager Einrichtung "Automatische Lagerbuchung" oder "Soll-Kosten buchen" aktiviert ist, kann das schon erheblichen Einfluss auf die Performance und das Lock-Verhalten haben, da hierbei sofort Buchungen in der Fibu erfolgen. Wie schon vorgeschlagen kann man statt automatischer Lagerbuchung die Lagerregulierung auch zu Zeiten laufen lassen, in denen keiner im System arbeitet (am Abend, am Wochenende...). Die Frage ist halt, wie aktuell müssen die Zahlen in der Fibu stehen - mit wirklich jeder Lagerbewegung, reicht einmal am Tag aktualisieren, oder vielleicht auch nur einmal die Woche...?

mfg
Phae

Wie groß ist eure DB, und wie viele Posten sind in den Posten Tabellen.
Eine weitere Frage: arbeitet ihr mit Dimensionen, womöglich allen möglichen? Falls ja, ist das evtl. das Grab des Servers. Die Auswertungen der Dimensionsinformationen, ist u.U. besser über einen Qube der SQL- Reporting Tools besser auszuführen.

Gruß, Fiddi

Hallo,

ersteinmal recht herzlichen Dank für die vielen Antworten in so kurzer Zeit.
Ich werd der Reihe nach versuchen Rede und Antwort zu stehen.

1. Verwendet wird die Version 4.0 SP3 (5.0 SP1). Es gab vor 2 Monten ein technisches Update um bestimmte Fehler in den Griff zu bekommen. Die Performance hat sich dadurch allerdings nicht gesteigert. Es wurde bei dem Performancetest auch nachgefragt ob unsere Anpassungen auf der Native-Datenbank entwickelt wurden und dann erst auf unser MS-SQL-System eingespielt wurden. Antwort: Nein, die Entwicklungsumgebung basiert auch auf MS-SQL.

2. Die Lagerregulierung wird zwar manuell angestoßen, läuft aber alle 1-2 Tage einmal durch. Das war bisher auch kein Problem, weil diese durch die wenigen Bewegungen recht schnell durch war und wir auch bis zum September nur eine Schicht hatten. Mittlerweile haben wir zwei Schichten, ab November Dreischichtbetrieb. Ab 2010 wird die Produktion die volle Kapazität erreicht haben und somit 24 Stunden 7 Tage die Woche produzieren.

Der Server auf dem Navision als einzige Anwendung läuft ist ein Intel XEON 2,4GHz Dualcore als 32Bit, mit 4GB RAM und 4 Segate a 500GB im Rate 1+0 verbund.
Wartungspläne wurde optimiert, Tracefiles und Datafiles liegen auf zwei physikalisch getrenten Platten.

Die Tabellocks sind echte Tabellocks. Zum Nachweis wurde auch ein Tabellockmonitor eingespielt. Die Lockingzeiten sind aus meiner Sicht sehr hoch.
Für Codeoptimierung auf den SQL-Server bezogen kenne ich mich leider zu wenig in der CAL-Programmierung aus, bzw komme mit der Lizenz hier auch nicht sehr weit. Deshalb kann ich da nicht wirklich auskunft geben.

3. In Lagereinrichtung ist der Haken "automatische Lagerbuchung" gesetzt, für "Soll-Kosten buchen" ist er nicht gesetzt.
Die aktualität der Zahlen muss nicht unbedigt Tagesgenau sein, aber eben mit der 24h 7d Produktion müssen alle Systembuchungen zu jeder Zeit durchführbar sein, ohne dass es auf andere Bereiche solche massiven Auswirkungen hat.

4. Die größe der Datenbank beläuft sich grad auf 8,7 Gigabyte, mit drei echten Mandanten und einem Testmandanten. Die größe der Tabellen für den einzigen wirklich wichtigen Mandanten ist aus meiner sich nicht wirklich viel. Die Warehouse-Entrytabelle hälst momentan etwas über 490.000 Einträge, die Dimension Ledger Entry 1,7 Mio Einträge, G/L Entry 1,3 Mio Einträge um die 3 größen zu nennen. Ein paar haben noch welche um die 50.000 Einträge alles andere weit darunter.

Die Sache mit den Dimensonen gibt mir auch grad ein wenig zu denken. Da hab ich aber in der Summe zu wenig Verständnis von. Ich bin der einzige Administrator und Betreuer und muss natürlich die ganze Bandbreite abdecken. Das Wissen und die Zusammenhänge wachsen bei mir aber bis zum Experten brauch ich glaub ich noch ein paar Stunden.

Gibt es Möglichkeiten die Auswirkungen der Dimensionen zu testen?

Gruß

Obsidian

Hallo Obsidian,

das mit den Dimensionen kriegst du nur raus, wenn du Sie mal in einer Testdatenbank deaktivierst, und dann mal das Buchungsverhalten anschaust.

Anhand deiner Hardwarebeschreibung habe ich die Befürchtung, das deine Platten ein wenig schwach dimensioniert sind (ich gehe mal davon aus, das es sich um 500GB SATA-Platten an einem Standard Onboard- Controller handelt).
Dies ist für Datenbanken eher suboptimal. Sinnvoll wäre hier ein SCSI o. SAS- System mit einem Cache-Controller mit Battery-Backup und aktiviertem Schreibcache. (Die USV für den Server nicht zu vergessen)
Da der SQL-Server eine Schreibtransaktion erst beendet, wenn die Daten auch tatsächlich auf der Platte angekommen sind (d.h. der Controller sagt, das er es getan hat ) dürfte hier der Flaschenhals liegen, weil er die Daten gleich auf zwei Platten schreiben müssen.

Kontrolliere doch mal mit dem Performance-Monitor von Windows, wie lang die Datenträger- Warteschlangen sind. Stehen hier jede Menge Anfragen drinn, wartet der Prozessor nur etwas schneller, aber er tut nichts, weil er keine Daten von der Platte bekommt bzw. los wird.

Gruß, Fiddi

Hi!

Nun, es wurde ja schon fast alles angesprochen, hier noch meine Kommentare: mit NAV & SQL Server kommen echte "Table-Locks" (TAB X) in der freien Natur nicht vor. Punkt. Eine Blockade auf einem derart hohen Eskalations Niveau bringt mit NAV eigentlich nicht hin. Was ist denn der "Tablellockmonitor"? Der "Session" Monitor von NAV ist denkabr ungeeignet für eine ernsthafte Block-Analyse ...
Es gibt allerdings Blockaden die - für das ungeübte Auge - aussehen wie Tabellensperren, die aber keine sind. Ich möchte zu diesem Thema auf mein BLOG verweisen:
http://dynamicsuser.net/blogs/stryk/archive/2008/11/03/blocks-amp-deadlocks-in-nav-with-sql-server.aspx

Eine 9GB "Micky Mouse" Datenbank sollte heute jeder mittelmäßige Server schlichtweg "weg-cachen" können, d.h. die Plattform scheint suboptimal dimensioniert oder konfiguriert zu sein (siehe meien Vorredner).
Aber: mit 4GB RAM stehen dem SQL Server zunächst nur ca. 1,6GB zur Verfügung. Erst wennd er /3GB Switch in der boot.ini gesetzt wird, können max. 2,6GB allokiert werden. Meine Erfahrungen zeigen bisher, dass man auch bei kleinen Datenbanken erst ab 8GB+ RAM glücklich wird ...
Uhm, hab ich's überlesen? Welchen SQL Server (Version/Edition/Build) setzt ihr ein?

Ein RAID10 (4 x HDD) für alles ist schwer ineffizient; wenn ihr tatsächlich zwei LW für mdf/ndf und ldf habt, dann ist das max. RAID1
Die absolute Mindestanforderung sieht so aus:
C:\ RAID1 (2x HDD) OS, Page File, Programme, SQL Server (master, model, msdb, tempdb)
D:\ RAID1 (2x HDD) NAV DB (mdf/ndf)
E:\ RAID1 (2x HDD) NAV DB (ldf) !!! UND SONST NIX !!!

Empfohlen (nachdem was ich bisher an Infos habe):
C:\ RAID1 (2x HDD) OS, Page File, Programme, SQL Server (master, model, msdb, tempdb)
D:\ RAID1 (2x HDD) SQL Server (tempdb)
E:\ RAID10 (4-6x HDD) NAV DB (mdf/ndf)
F:\ RAID1 (2x HDD) NAV DB (ldf) !!! UND SONST NIX !!!

Bleibt noch die Frage: wohin mit den Backups?

Auf meinder Web-Seite stelle ich eine Performance Checkliste zur Verfügung; anhand derer könntest Du mal dein System "abklopfen": http://www.stryk.info/Performance%20Checklists%201.08.pdf

Und: was für "Optimierungen" wurden denn schon durchgeführt?

Und zu guter letzt der Werbeblock: http://www.amazon.de/Performance-Guide-Trouble-Microsoft%C2%AE-Dynamics/dp/3837014428/ref=sr_1_1?ie=UTF8&s=books&qid=1197564359&sr=1-1 (Achtung: in wenigen Wochen erscheint die neue Ausgabe!)

Schönes Wochenende,
Jörg

Ich würde mal zwei Maßnahmen testen :
Die automatische Lagerregulierung einschalten, aber die automatische Lagerbuchung ausschalten.

Durch die erste Maßnahme wird die Buchungszeit der einzelnen Buchung zwar etwas länger, aber es gibt keine langen Regulierungen mehr die durch alle Artikel laufen müssen und längere Zwangspausen verursachen. Außerdem gilt innerhalb der Warenwirtschaft, je schneller reguliert wird, desto besser, weil dann sofort der durchschnittliche Einstandspreis aktualisiert wird. Falls die Maximalstufe "Immer" zu lange dauert, kann man das ggf. auf die Perioden einschränken. Auch dann ist das Gros schon erledigt wenn die manuelle Regulierung gestartet wird.

Durch das Abschalten der automatischen Lagerbuchung werden die Buchungen im Tagesgeschäft auf den Lager-und Verbrauchskonten abgestellt. Beim Verkauf und Einkauf werden die Sachposten für Erlöse, Aufwand, Forderungen und Verbindlichkeiten und die Steuerposten immer sofort erstellt, das kann man nicht abschalten. Es ist aber normalerweise nicht notwendig, auch jede Lageraktivität sofort abzubilden. Die können z.B. auch einmal im Monat durchgeführt werden, wenn die Zahlen auf diesen Konten nicht tagesaktuell sein müssen, und ohne dass die Genauigkeit darunter leidet. Das kann man auch gut nachts laufen lassen, ich vermute mal, dass trotz des Dreischichtbetriebs dann keiner in der Buchhaltung arbeitet .

Das Problem, dass die Dimensionstabellen (sozusagen der Nabel der Buchungssystematik) bei Verwendung von Dimensionen immer angesprochen werden, lässt sich so zwar auch nicht vermeiden, aber die sind von der Datensatzgröße im Vergleich zu den Sachposten sehr klein und haben auch nicht eine ganze Batterie von Sekundärschlüsseln, werden beim Buchen also deutlich schneller vom Server "erschlagen".

Hallo zusammen,

recht herzlichen Dank für die vielen Anregungen und Hinweise.
Ich werde das mit den Lagerregulierungen und die Lagerbuchungen testen, genau wie das mit den Dimensionen.
Anhand der zahlreichen Hinweise habe ich beschlossen mit unserem Implementierungspartner nochmal ins direkte Gespräch zu treten, was diese Sache betrifft.
In der Summe habe ich jetzt mitgenommen, dass sowohl die Hardware generell unterdimensioniert scheint (obwohl eine Experte den Server und die Einstellungen als ausreichend dimensioniert bezeichnet hat) und dass es etliches an Stellschrauben gibt, die massiven Einfluss auf das langsame Verhalten haben können.
In der Hinsicht hatten wir uns eigentlich auf das Know How und die Beratungsleistung unseres Implementierungspartners verlassen, aber irgendwie fühl ich mich grad ein wenig allein gelassen, zumal ich schon seit geraumer Zeit immer wieder massive Performanceprobleme mitteile die mit steigender Belastung des Systems immer deutlicher zu Tage treten kommuniziert habe, von der eine schon eskaliert wurde, mit mäßigem Erfolg.

Ich denke ich habe den Überblick bekommen, dass dieses Verhalten bei uns definitiv nicht normal sein kann!
Jetzt liegt es an mir die Sachlage richtig zu vertreten.

Ich werde Euch über die Eckpunkte des Verlaufs berichten, denn passieren muss etwas, sonst geht das hier bald schief!

Schöne Grüße und recht herzlichen Dank an Alle

Obsidian

Was ist denn nun passiert? Könnte auch andere User interessieren wie das Problem gelöst wurde oder ob inzwischen eine andere ERP eingesetzt wird. Klingt ja nicht gerade verkaufsfördernd, was hier alles so über einen Solutionpartern gesagt wurde.

Hallo,

Klingt ja nicht gerade verkaufsfördernd, was hier alles so über einen Solutionpartern gesagt wurde.

Ich gebe dir teilweise Recht. Es kommt aber auch oft vor, das wegen eines zu kleinen Budgets schwächere Hardware angeschafft wird, und nachher kann sich niemand mehr daran erinnern, warum ein schwachbrüstiges System gekauft wurde. Es kommt aber auch vor, dass der Verkäufer ein kleineres System anbietet, um den Auftrag nicht zu gefährden, weil er dem Kunden keinen Rechner für 10000€ anbieten kann .
Es ist aber auch schwer einem Kunden klar zu machen, der mit NAV2.6 auf einem kleinen Server angefangen ist, und jetzt auf ein neues System (NAV>=Version 4) und SQL umsteigen will/muss, warum er auf einmal so eine "große Kiste" benötigt.
Das er damit einen unzufriedenen Kunden hat, interessiert da erst mal nicht wenn der Umsatz stimmt .

Auf der anderen Seite steigen viele Partner erst von einer nativen-DB auf den SQL-Server um. Das bedeutet, das man sich Know- How in dem Bereich aneignen muss, das funktioniert mit Schulungen und erreichten Zertifizierungen nur begrenzt. Man muss hier bei beachten, dass die höheren Hardwareanforderungen des SQL- Servers mit immer größer werdenden Datenbanken zusammentreffen, was eine Dimensionierung am Anfang sehr schwer macht.
Da den Schritt zu gehen, wir dimensionieren auf jeden Fall ausreichend, auch wenn es teurer wird, fällt schwer, wenn man einen Mitbewerber hat der das evtl. anders sieht, oder einen Kunden hat, der das Geld dafür nicht ausgeben kann oder will.

Oft sind die Hardwarepartner, die nichts mit dem ERP- Partner zu tun haben, auch keine Datenbank- Spezialisten, die die Anforderungen eines DB-Servers an die Hardware kennen. Da werden munter Virtualisierungssysteme verkauft, bei denen n Server auf einer Maschine laufen, und alle VMs teilen sich ein großes RAID5 des VM-Servers, und hinterher wundern sich alle, warum NAV so langsam ist.

Gruß, Fiddi

Es ist ja nicht so, als ob es keine anderen Beispiele gäbe. Der SQL-Server, den uns unserer Partner vor knapp drei Jahren empfohlen hat, entsprach damals recht genau dem, was zB von Jörg hier auch angeraten wurde (wobei auch gesagt wurde, dass alles Kleinere Sparen am falschen Ende sei), und er läuft bis heute schnell und zuverlässig :)

wobei auch gesagt wurde, dass alles Kleinere Sparen am falschen Ende sei

Das versuche ich unseren Kunden auch immer klar zu machen . Am Ende schauen sie dann auf die Angebote, und entscheiden sich oft nicht für das preiswertere, sondern das billigere

Gruß, Fiddi

Am Ende schauen sie dann auf die Angebote, und entscheiden sich oft nicht für das preiswertere, sondern das billigere

... was umso unverständlicher wird, wenn man sich die Kosten der Wartungs- und Lizenzgebühren über ein paar Jahre ansieht. Was hätte da ein etwas günstigerer Server schon ausgemacht?

Ein generelles Verurteilen der Partner halte ich für absoluten Unsinn. Es ist wie überall im Leben, es gibt solche und solche.
Ich habe aber den Eindruck, daß es teilweise auch an der Mentalität in Deutschland liegt. Wenn man selbst von einem Problem nur wenig Ahnung hat bzw. nicht ausreichend, dann ist es eigentlich schon mal eine große Leistung das zu erkennen und sich einzugestehen. Aber den Schritt zu tun und noch einen anderen (evtl. externen) Experten hinzuzuziehen, machen dann doch wenige. Sei es übertriebener Ehrgeiz, gekränkte Eitelkeit, mangelnde Selbsteinschätzung,... oder einfach nur Kostenersparnis (-druck), ich denke, da können wir alle noch was lernen. Ich vergleiche das immer ganz gerne mit den Ärzten. In Deutschland scheuen sich die meisten Ärzte, einen Patienten an einen Kollegen aus der gleichen Fachrichtung zu verweisen, wenn sie nicht mehr weiterkommen. In den USA ist das gang und gäbe. Es ist doch nicht so, daß man damit mangelnde Kompetenz oder einen Fehler eingesteht, vielmehr ist es so, daß man auch die Verantwortung gegenüber dem Kunden übernommen hat, alles Menschenmögliche zu tun, um der Probleme Herr zu werden. Das IT-Feld ist mittlerweile so komplex und weitreichend, daß es nicht mehr den einen Experten gibt, wie vielleicht noch in den 80ern, sondern viele unterschiedlichste Experten für unterschiedlichste Bereiche. Und da ist mir persönlich jemand lieber, der verantwortlich die Probleme koordiniert und evtl. delegiert, als jemand, der meint, die Weisheit mit Löffeln gefressen zu haben, und zuguckt wie der Kunde langsam an seinen Problemen verzweifelt, weil er sich keine Hilfe holen möchte.

@HattrikHorst

Dem ist eigentlich nichts mehr hinzuzufügen.

HattrickHorst,

dankeschön für dieses Statement. Das kann ich nur unterstreichen. Was deinem Beitrag an Formatierung fehlt, macht er durch Realitätsnähe wieder wett

Hallo zusammen,
ich hätte da noch eine Frage zur tempdb, vielleicht an Jörg, weil er das oben so schön aufgelistet hat, aber auch an die anderen:
In der von Jörg empfohlenen RAID Verteilung, ist es da performancemäßig besser, die Dateien der tempdb auf C: und D: aufzuteilen? Also die tempdb.mdf zusammen mit dem Betriebssystem auf C: und die templog.ldf allein auf D:? Oder besser beide Dateien zusammen auf D:?
Grüße
Markus

Hallo,

also die Tempdb auf c: ist vielleicht nicht so das optimale. Wenn das (aus Performancegründen) wirklich wichtig wird, sollte man evtl. über eine SSD dafür nachdenken.

Gruß, Fiddi

Hallo zusammen,
ich hätte da noch eine Frage zur tempdb, vielleicht an Jörg, weil er das oben so schön aufgelistet hat, aber auch an die anderen:
In der von Jörg empfohlenen RAID Verteilung, ist es da performancemäßig besser, die Dateien der tempdb auf C: und D: aufzuteilen? Also die tempdb.mdf zusammen mit dem Betriebssystem auf C: und die templog.ldf allein auf D:? Oder besser beide Dateien zusammen auf D:?
Grüße
Markus

Also wie so oft: es hängt davon ab ...

Bei kleinen Systemen mit geringem Volumen kann man die tempdb schon mit auf C:\ (RAID1) lassen, vorausgesetzt es ist ein dedizierter Server, der außer NAV/SQL nicht viel macht - das OS alleine erzeugt nicht viel I/O, so dass die tempdb funktionieren kann.
Eine Ausbaustufe kann z.B. sein C:\ als kleines RAID10 zu bauen, davon profitiert auch die "tempdb".
Besser ist ein dediziertes physikalisches Laufwerk für die "tempdb" zu haben, zwecks separatem I/O. Klein-Mittel RAID1, MITTEL-GROSS RAID10.
Die "tempdb" sollte man in meherer gleich große Daten-Dateien aufsplitten, dabei soviele Daten wie man CPU hat (sagt MS, ich rate es etwas vorsichtiger angehen zu lassen:
bei 4 CPU: 2- 4 Dateien
bei 8 CPU: 4 - 8 Dateien
bei >= 12 CPU: 6 - 12 Dateien
)
Natürlich muss es bei einer Log Datei bleiben! Für alle dateien sollte die Init-Größe auf das "erwartete Maximum" gesetzt werden, also je nach Systemgröße 1000 bis 5000 MB (Auto Growth fix, 500 bis 1000 MB). Eine "Abspaltung" des Log der "tempdb" auf ein eigenes Laufwerk ist eher nicht notwendig.

Hallo,
vielen Dank an fiddi und Jörg mit seiner umfassenden Antwort. Damit sind meine Fragen mehr als beantwortet!
Gruß
Markus