در واقع latch ها مکانیزمهایی هستند که از نواحی SGA در مقابل همزمانی کار و خرابی روی دیتا در memory محافظت می کنند (مانند enqueue ها که همین کار را در سطح row پیش می برند). به طور کلی lock ها در دیتابیس اوراکل به دو دسته تقسیم می شوند: enqueue ها و latch ها. در خصوص محافظت از همزمانی کار با دیتا در سطح row و یا table مکانیزم های enqueue وارد عمل می شوند (row lock contention) و در خصوص محافظت از همزمانی کار با دیتا در سطح memory مکانیزم های latch را داریم.
زمانی که یک session نیاز به update مقادیری از دیتا را دارد این کار را روی کپی دیتای هدف در SGA انجام می دهد و اصطلاحا آن را latch می کند (یعنی آن را محکم نگه می دارد) و اگر همان دیتا توسط همان session یا session دیگری مورد نیاز باشد، درخواست latch جدید روی دیتا تا اتمام عملیات قبلی تائید نمی شود و اوراکل پس از چند بار تلاش (الگوریتم spin lock تعداد مشخصی spin را با توجه به تنظیم پارامتر spin_count پیش از به خواب رفتن امتحان می کند) درخواست latch را در وضعیت sleep قرار می دهد.
معرفی latch هایی که بیش از سایرین بر روی کارایی تاثیر می گذارند:
از نوع library cache و shared pool: این latch ها از library cache محافظت می کنند که محل ذخیره دستورات SQL قابل اشتراک گذاری است. اگر طراحی application صحیح باشد این نوع latch کمتر دچار contention می شود. مثلا در برنامه هایی که به جای bind variable از مقادیر مشخص و ثابت در کد استفاده شده است این نوع مشکل شایع می شود.
از نوع redo copy و redo allocation: این latch ها از redo log buffer محافظت می کنند که محل ذخیره redo entry ها است. این نوع latch در نسخه های اخیر اوراکل کمتر بروز می کند.
از نوع cache buffer chain: این latch ها زمان خواندن و نوشتن دیتا در buffer cache رخ می دهند که در واقع از دیتابلاکهای کپی شده در memory در برابر همزمانی کار محافظت می کنند. به طور معمول دیتابلاکهای داغ (hot blocks) دچار این نوع contention می شوند.
جهت شناسایی latch ها از v$latch استفاده کنید. ستون misses تعداد کلی دفعات تلاش ناموفق برای گرفتن latch را نشان می دهد و ستون sleeps تعداد دفعاتی که پس از چند بار تلاش (با توجه به spin_count تنظیم شده) session دچار sleep می شود.
@BIMining
مه 
