Unter Windows und Linux werden Worker-Threads unter Verwendung von Lightweight-Threads ausgeführt, die auch als Fasern ("fibers") bezeichnet werden. Eine Implementierung, die Fasern verwendet, gestattet es Worker-Threads, die Abfolgeplanung kooperativ untereinander festzulegen, anstatt sie mit dem Betriebssystem-Scheduler vorab festzulegen. Das Ergebnis ist, dass ein Kontextwechsel zwischen Fasern genauer gesteuert werden kann. Der Datenbank-Kernel erstellt den Zeitplan für die Fasern, um die Prozessoraffinität zu maximieren und die Ausführungspriorität jedes Worker-Threads genau zu steuern.

Da Fasern nicht vom Betriebssystem-Scheduler abhängen, muss eine Faser die Kontrolle an eine andere Faser explizit übergeben, wenn sie auf den Abschluss einer anderen Aktivität wartet. Wenn z.B. eine auf einer Faser ausgeführte Aufgabe blockiert, während sie auf den Abschluss eines I/O-Vorgangs wartet, übergibt sie die Kontrolle an eine andere Faser. Der Thread, der die ursprüngliche Faser ausführt, kann unmittelbar eine andere Faser entgegennehmen und ihre Ausführung ohne einen Kernel-Kontextwechsel beginnen. Wenn eine Faser blockiert und die Kontrolle nicht übergibt, blockiert sie den Thread, der sie beherbergt, und hindert damit andere Fasern daran, auf diesem Thread zu laufen. Wenn mehr als ein Thread Fasern beherbergt, wird nur der Thread, der die wartende Faser beherbergt, blockiert: Andere Threads können weiterhin Fasern verarbeiten.

Auf Windows- und Linux-Plattformen werden zumindest so viele Fasern erstellt, wie es die Einstellung für die maximale Parallelität des Datenbankservers erfordert (durch die Option -gnh angegeben). Der Datenbankserver verwendet eine Teilmenge dieser Fasern während der Serverausführung, entsprechend der aktuellen Multiprogramming-Stufe des Servers. Für jede Faser muss das Betriebssystem Adressraum für ihren Stack reservieren. Der für jede Faser erforderlich Stackbereich hängt von der Einstellung der Serveroption -gss ab. Siehe -gss - dbeng12/dbsrv12-Serveroption.

Der von einem Netzwerkserver benötigte Adressraum für Ausführungsstacks ist proportional zur maximale Multiprogramming-Stufe. Siehe --gn - dbsrv12-Serveroption.