Background Process ها، فرایند هایی هستند که در پس زمینه و پشت صحنه در حال اجرا شدن هستند. کاربران هیچگونه تعاملی با این فرایند ها ندارند و در سیستم عامل های یونیکسی (لینوکس و یا هر سیستم عامل دیگر) توسط فرایند آغازین init راه اندازی (start) می شوند و پس از راه اندازی در پشت صحنه به اجرای خود ادامه می دهند و بدون تعامل با کاربر به درخواست های رسیده پاسخ می دهند. در اوراکل فرایند های پس زمینه در قالب View به نام V$PROCESS سازماندهی شده اند.
;select pid, pname from v$process
در خروجی شکل بالا، اگر ستون pname برای یک pid (یا شنایه فرایند) دارای نام باشد (یعنی not-null value)، آنگاه یک فرایند پس زمینه مربوط به اوراکل است که وظیفه ای خاص را در Instance انجام می دهد. توجه کنید که یک Instance متشکل از حافظه و فرایند های پس زمینه می باشد. در سیستم عامل های یونیکسی مانند سولاریس و سیستم عامل لینوکس، فرایند های پس زمینه اوراکل در غالب فرایند های جداگانه در حال اجرا شدن هستند و این در حالی است که در سیستم عامل ویندوز تمامی فرایند های پس زمینه اوراکل در غالب Thread هایی (نخ هایی) در یک فرایند به نام ORACLE.EXE در حال اجرا شدن هستند. برای مشاهده فریاند ORACLE.EXE در سیستم عامل ویندوز برنامه task manager را باز کنید و مطابق شکل زیر از برگه Processes روی Show processes for all users ها کلیک کنید و در پنجره به دنبال فریاند oracle.exe بگردید.
و همچنین در سیستم عامل لینوکس با استفاده از دستور زیر می توانید فهرست فرایند های پس زمینه را ببینید. همانطور که مشاهده می کنید در ستون TTY یک علامت سوال یا ? آمده است و این نشانگر این است که یک فرایند پس زمینه (که در سیستم عامل های یونیکسی Daemon می گویند) است. (یعنی توسط خود سیستم و بدون هیچگونه تعامل با کاربر ایجاد شده است، چرا که کاربر برای ایجاد فرایند باید دستوری را در یک ترمینال مانند tty1 اجرا کند.
ps -ef | grep ora_ | grep -v “grep ora_” | less
همچنین با استفاده از Query زیر میتوانید فرایند های پس زمینه را مشاهده کنید. نخستین شکل مربوط به خروجی در سیستم عامل لینوکس و دومین شکل زیر مربوط به سیستم عامل ویندوز است و همانطور که مشاهده می کنید، تمامی فرایند های پس زمینه بعنوان نخ هایی (Thread هایی) از فرایند oracle.exe هستند.
;’select SID,PROGRAM from v$session where TYPE=’BACKGROUND
برخی از این فرایند ها باید بصورت دائمی و اجباری برای Instance هستند و در صورتی که وجود نداشته باشند، Instance دچار Abort خواهد شد. تمامی فرایند ها در در هنگام راه اندازی Instance، فعال (Instance startup) می شوند. فرایند های اجباری عبارتند از : DBWn, LGWR, CKPT, SMON, PMON و فرایند RECO. در ادامه فرایند ها را شرح می دهم.
- فرایند Database Writer یا DBWR
این فرایند بصورت DBWR0 تا DBWR9 و DBWRa تا DBWRj نامگذاری می شوند و حداکثر تعداد 20 تا می تواند در یک Instance وجود داشته باشد. وظیفه آن نوشتن بلاک های تغییر یافته بافر بر روی Data File ها می باشد. یک فرایند DBWn برای سیستم کافی است. پارامتر DB_WRITER_PROCESSES بر روی تعداد این فرایند کنترل دارد. بصورت پیش فرض مقدار آن 1 است و به معنی وجود تنها یک فرایند است.
show parameters db_writer_processes
NAME TYPE VALUE
———————————— ———– ——
db_writer_processes integer 1
با در نظر گرفتن تعداد پردازنده های (CPU های) قرار داده شده در سیستم، می توانید تعداد فرایند DBWRn را با تغییر پارامتر بالا، چند تایی کنید. رفتار این فرایند به این صورت اسن که :وقتی که dirty blocks ها در ناحیه SGA به مقدار سر حد می رسند، اوراکل فرایند DBWRn را فراخوانی می کند. منظور از dirty blocks، آن بلاک هایی از SGA که تغییر کرده اند، یعنی روی آنها نوشته شده است. برخی دیگر از بلاک ها وجود دارند که هنوز روی آنها چیزی نوشته نشده است که free block گویند. معماری پایگاه داده ها از فضایی از حافظه اصلی برای بار کردن داده ها از پایگاه داده فیزیکی یا Data File ها استفاده می کنند. به عمل بار کردن داده ها از ناحیه فیزیکی (دیسک) به حافظه اصلی (Cache) عمل Fetch و به عمل انتقال بلاک های تغییر یافته یا dirty block ها به دیسک که توسط DBWRn در اوراکل انجام می گیرد عمل Flush گویند.DBWRn هر سه ثانیه یکبار بررسی می کند که آیا dirty block ای وجود دارد یا نه؟
- فرایند Log Writer یا LGWR
این فرایند محتوای بافر Redolog را بر روی Redo Log File ها (مطالعه کنید بخش های 1 و 2 و 3) می نویسدو این بافر شامل تمامی تغییراتی است که انجام شده و قرار است بر روی Data File ها نوشته شود. توجه داشته باشید ر پایگاه داده ها پیش از اعمال تغییرات بصورت دائمی در پایگاه داده، برای برآوردن اعمال ترمیم، حتما می بایست یک نسخه از تغییرات بر روی Redo Log File ها نوشته شود. در اوراکل این کار توسط فرایند LGWR انجام می گیرد. تعداد این فرایند حداکثر می تواند یک عدد باشد.
Redo Log File ها در سه حالت قرار می گیرند : CURRENT یا ACTIVE و یا INACTIVE. فایل Redo Log ای که به تازگی ایجاد شده است در حالت UNUSED قرار دارد. وقتی فرایند LGWR در حال بازنویسی محتوای Redolog Buffer بر روی فایل Redo Log است، آن فایل در حالت CURRENT قرار می گیرد. زمانی که فایل Redo Log بطور کامل پر شد، آنگاه فرایند LGWR به فایل دوم سوئیچ می کند. فایلی که پر شده است در حالت ACTIVE قرار دارد، یعنی از حالت CURRENT (در حال نوشتن بر روی آن توسط LGWR) به حالت ACTIVE (حالتی که توسط LGWR نوشته شده و بطور کامل پر شده است)، تغییر حالت می دهد.
- فرایند System Monitor یا SMON
این فرایند در زمان startup یک instance، در صورت لزوم عمل Recovery را انجام می دهد. همچنین برای پاک کردن (Cleaning up) سگمنت های موقتی که مدتی است دیگر مورد استفاد قرار نمی گیرند. همچنین فضای SYSTEM Tablespace را بررسی (مانیتور) می کند.
- فرایند Process Monitor یا PMON
این فرایند عمل ترمیم (Recovery) را وقتی که یک User Process دچار fail می شود را انجام می دهد. این فرایند مسئول پاک کردن database buffer cache و بازپس گیری منابعی که کاربر در حال استفاده آنها بوده است. مانند بازپس گیری قفل ها از فرایند کاربر، حذف شناسه فرایند کاربر از فهرست فرایند های فعال یا Active Processes. شکل زیر گویای ارتباط فرایند کاربر و فرایند های پس زمینه می باشد.
برای مطالعه بیشتر می توانید این فایل را بخوانید و یا اینکه این پیوند را بخوانید.
