မူလလက္ေဟာင္း ... ငါေတာ့ေမ့လုိ႔မရႏုိင္ဘူး။

မူလလက္ေဟာင္း Angry Bird ကုိ ယေန႔အထိ ကြၽန္ေတာ္တုိ႔ ေမ့မရႏုိင္ေသးပါ။

ပံုကုိ www.themetapicture.com မွ ကူးယူေဖာ္ျပပါသည္။

ဘဲႏႈတ္ခမ္းနဲ႔ မမေလးမ်ား သတိထား

ဘဲႏႈတ္သီးလုိ ႏႈတ္ခမ္းစူၿပီး ရုိက္ထားတဲ့ ဓာတ္ပံုေတြကုိ Facebook မွာ တင္တတ္သူ မမေလးမ်ား ဘဲပစ္ရာသီေရာက္ၿပီဆုိၿပီး အပစ္ခံရမွာ သတိထားၾကေနာ။

Warner Brothers က Looney Toons ေတြထဲမွာ ဘဲပစ္ရာသီ၊ ယုန္ပစ္ရာသီဆုိၿပီး အမဲလုိက္သမားေရွ႕မွာ ယုန္နဲ႔ ဘဲနဲ႔ ဝုိင္းျငင္းၾကတဲ့ ကာတြန္းဟာ အင္မတန္ နာမည္ႀကီးပါတယ္။

၀င္းဒုိးပဲ သံုးတာရွင့္

ကြန္ပ်ဴတာ ျပဳျပင္ ထိန္းသိမ္းေရး ဝန္ေဆာင္မႈဌာနတြင္ တယ္လီဖုန္း ျမည္လာသည္။

ကြန္ပ်ဴတာ ဝန္ထမ္း။ ။ ဟုတ္ကဲ့၊ ကြန္ပ်ဴတာဌာနကပါ။ 

ဖုန္းေခၚလာသူ စာရင္းကုိင္ ဝန္ထမ္း။ ။ ကြၽန္မ ကြန္ပ်ဴတာ အင္တာနက္သံုးမရေတာ့လုိ႔ပါ။ 

ကြန္ပ်ဴတာ/ထမ္း။ ။ စက္ပိတ္ၿပီး ျပန္ဖြင့္ၾကည့္ပါလား။ 

စာရင္းကုိင္/ထမ္း။ ။ မရဘူးရွင့္။ 

ကြန္ပ်ဴတာ/ထမ္း။ ။ အစ္မစက္ရဲ႕ MAC Address ေလးတခ်က္ေလာက္ ေျပာျပပါလား။ 

စာရင္းကုိင္/ထမ္း။ ။ ကြၽန္မတုိ႔ ဌာနမွာ ၀င္းဒုိးပဲ သံုးတာပါရွင့္။ ပန္းသီး ကြန္ပ်ဴတာ မသံုးပါဘူး။ ရွင္ ကြန္ပ်ဴတာဌာနမွာ အလုပ္လုပ္ေနၿပီး ဒါေလးေတာင္ မသိဘူးလား။ !@#$%^&*()

မွတ္ခ်က္။ ။ MAC Address = Media Access Control address ကြန္ရက္ခ်ိတ္သည့္ စက္ပစၥည္း တစ္ခုစီတုိင္းတြင္ ရွိရေသာ ဒြိကိန္း ၄၈ လံုးပါ လိပ္စာ။ 

SQL Statement Level တြင္ Optimize လုပ္၍ Query Execution ကုိ ျမန္ဆန္ေစျခင္း

မေန႕က စာေရးသူ အိမ္ကုိ ျပန္ေနတုန္း အစ္မေတာ္က ခ်က္ခ်င္းပဲ G-talk ေပၚကုိ ၾကြပါလုိ႕ Message ပုိ႕လာပါတယ္။ ဒါနဲ႕ပဲ ဖုန္းကေန G-talk ကုိ ဖြင့္လုိက္ေတာ့ Query တစ္ခုကုိ run ထားတာ ၃ နာရီ နီးပါးရွိၿပီ၊ အေျဖမထြက္ေသးလုိ႕ ဘယ့္ႏွယ္လုပ္ရပါ့လုိ႕ ေမးပါေတာ့တယ္။ ဒီ စာတမ္းငယ္မွာ အလားတူ ျပႆနာတစ္ရပ္ (အေရးႀကီး အခ်က္အလက္မ်ား ပါ၀င္ေနသျဖင့္ မူလျပႆနာကုိ မေဖာ္ျပႏုိင္ပါ) ကုိ SQL Statement Level မွာ Optimize လုပ္ပံုကုိ ေရးသားေဖာ္ျပမွာ ျဖစ္ပါတယ္။

ပရိေဘာဂနဲ႕ မီးဖုိေခ်ာင္သံုး ပစၥည္း ေရာင္းတဲ့ကုမၸဏီတစ္ခုမွာ ေဖာက္သည္ေတြရဲ႕ အမည္၊ ေမြးေန႕၊ လိပ္စာ၊ ဖုန္းနံပါတ္၊ အခ်က္အလက္ေတြကုိ Table တစ္ခုနဲ႕ သိမ္းထားပါတယ္ (Customer Table ဆုိပါစုိ႕)။ ေဖာက္သည္ေတြ ပစၥည္း မွာယူတုိင္းမွာ အမွာလက္ခံတဲ့ Table တစ္ခုလဲ ရွိပါတယ္ (Order Table ဆုိပါစုိ႕)။ Order Table ဟာ ကုမၸဏီ သက္တမ္းၾကာတာနဲ႕အမွ် အရမ္းႀကီး လာတတ္လုိ႕ Production run ေနတဲ့ server မွာ ၃ - ၄ ႏွစ္စာပဲ ထားၿပီး က်န္တာကုိ သပ္သပ္ သိမ္းထားေလ့ ရွိပါတယ္။

ျဖစ္ပံုက ပရိေဘာဂ မ၀ယ္ဖူးေသးတဲ့ (မီးဖုိေခ်ာင္သံုး ပစၥည္းပဲ ၀ယ္ဖူးတဲ့) ေဖာက္သည္ေတြကုိ အထူး အေရာင္းျမွင့္တင္ေရး အစီအစဥ္နဲ႕ ပရိေဘာဂေတြ ေစ်းခ်ေရာင္းမဲ့ အေၾကာင္း ေၾကာ္ျငာစာ ပုိ႕ခ်င္တာပါပဲ။ အဲဒါနဲ႕ ေအာက္ပါ Query ကုိ ေရးပါတယ္။

SELECT cust_id, cust_name, cust_add

FROM customer_table

WHERE cust_id NOT IN (SELECT cust_id FROM order_table WHERE ord_type = ‘furniture’);

အဲဒီလုိ ေရးလုိက္တဲ့ Query ဟာ ၃ နာရီနီးပါး ၾကာတဲ့အထိ မၿပီးႏုိင္လုိ႕ စာေရးသူကို အပူကပ္ျခင္း ျဖစ္၏။ ဘာျဖစ္သနည္း အေျဖရွာေသာ္ ...

ကုမၸဏီသည္ ပရိေဘာဂ အမွာစာ အမ်ားအျပား လက္ခံရရွိခဲ့ရာ Sub-query မွ Row အေျမာက္အမ်ားကုိ ထုတ္ေပးေလသည္။ Row ၃ ေသာင္းေက်ာ္တဲ့။ Customer Table တြင္လဲ Row အမ်ားအျပား ရွိေပလိမ့္မည္။ ယခု ေဆြးေႏြးခ်က္တြင္ Customer Table ၏ Size မွာ အေရးမႀကီးပါ။ Query Optimizer သည္ Sub-query မွ constant results ကုိ ထုတ္ေပးေၾကာင္း သိသျဖင့္ Sub-query ကုိ တစ္ႀကိမ္သာ Run မည္ပဲထား၊ Customer Table မွ Row တစ္ေၾကာင္းစီ (cust_id တစ္ခုစီ) အား Sub-query မွ ေပးေသာ Row ၃ ေသာင္းေက်ာ္တြင္ ပါ၊ မပါကုိ စိစစ္ရန္မွာ လြယ္ကူေသာ အလုပ္ မဟုတ္ေခ်။ အဘယ္ေၾကာင့္ဆုိေသာ္ တၿပိဳင္နက္ အသံုးျပဳသူ အေျမာက္အမ်ားရွိတတ္ေသာ Database Server တြင္ အသံုးျပဳသူတစ္ေယာက္ (Query တစ္ခု) အတြက္ ခြဲေ၀ေပးေသာ ပင္မ မွတ္ဥာဏ္ (Primary Memory or RAM) ပမာဏသည္ အကန္႕အသတ္ ရွိသည့္အျပင္ Order Table တြင္ cust_id ျဖင့္ index တစ္ခု မရွိႏုိင္ျခင္းေၾကာင့္ ျဖစ္သည္။

မွတ္ခ်က္ ။ ။ စာျပန္ဖတ္ၾကည့္ရာ NOT IN ျဖင့္ေရးလွ်င္ Sub-query ကုိ အႀကိမ္ႀကိမ္ run လိမ့္မည္ျဖစ္ၿပီး cust_id ျဖင့္ index ရွိလဲ မသံုးဟု ဆုိသည္။ NOT EXISTS ျဖင့္ ေျပာင္းေရးလွ်င္ေတာ့ အဆုိပါ Index ကုိ သံုးေကာင္း သံုးႏုိင္သည္။ အကယ္၍ Order Table အတြက္ cust_id ျဖင့္ index တစ္ခု၊ ord_type အတြက္ Index တစ္ခုရွိပါက NOT EXISTS ကုိ သံုးျခင္းျဖင့္ အေျဖ ျမန္ျမန္ ရႏုိင္သည္ ဆုိသည္။ သုိ႕ရာတြင္ Transaction Table ျဖစ္ေသာ Order Table ၏ Primary Key မွာ Composite ေသာ္လည္းေကာင္း၊ Order Number ေသာ္လည္းေကာင္း ျဖစ္မည္ ျဖစ္ၿပီး မည္သည့္ စိတ္မွန္ေသာ Database Administrator မွ် ၂ ႏွစ္ေနလုိ႕ တစ္ခါ မလုပ္ေသာ အေရာင္းျမွင့္တင္ေရးအတြက္ အဆုိပါ index မ်ားကုိ ေဆာက္ထားမည္ မဟုတ္။ Index ေဆာက္ျခင္းသည္ Insert ႏွင့္ Update Query မ်ားအတြက္ စြမ္းေဆာင္ရည္ကုိ က်ဆင္းေစသည္။

သုိ႕ျဖစ္၍ Customer Table မွ cust_id တစ္ခုစီအား Sub-query မွ ေပးေသာ Row ၃ ေသာင္းေက်ာ္အတြင္း ပါ၊ မပါကုိ စိစစ္ရန္ cust_id တစ္ခုစီအတြက္ Sub-query အေျဖ ၃ ေသာင္းေက်ာ္ကုိ တစ္ႀကိမ္စီ ဖတ္ရမည္ ျဖစ္သည္။ Sub-query အေျဖ ၃ ေသာင္းေက်ာ္သည္ ပင္မ မွတ္ဥာဏ္အတြင္း မဆန္႕ျပန္ရာ ၄င္းတုိ႕ကုိ အစိတ္စိတ္ပုိင္း၍ အရန္ မွတ္ဥာဏ္ (Auxiliary Memory or Disk) သုိ႕ ေရးကာ ျပန္ျပန္ဖတ္ရမည္။ အရန္ မွတ္ဥာဏ္သို႕ ေရး/ဖတ္ ရသည့္ အလုပ္သည္ ေႏွးေကြးေသာ အလုပ္ျဖစ္သျဖင့္ Customer Table မွ cust_id တစ္ခုအတြက္ CPU Cycle အမ်ားအျပား ၾကာျမင့္မည္။ ထုိၾကာေသာ အလုပ္ကုိ Customer Table အတြင္းမွ ေျမာက္မ်ားစြာေသာ Row မ်ားအတြက္ အခါခါ လုပ္ရရာ ၃ နာရီ နီးပါး ၾကာေသာ္လည္း မၿပီးသည္မွာ မဆန္း။

နည္းလမ္းစဥ္ သရုပ္ခြဲခ်က္ (Algorithm Analysis) အရ Customer Table တြင္ Row n ခု၊ Order Table တြင္ Row m ခု၊ ပင္မ မွတ္ဥာဏ္တြင္ cust_id ေပါင္း p ခု သိမ္းဆည္းထားႏုိင္၍ cust_id ေပါင္း p ခုကုိ ပင္မ မွတ္ဥာဏ္အတြင္းသို႕ ကူးယူရန္ အခ်ိန္ c ၾကာသည္ဆုိပါက ပင္မ မွတ္ဥာဏ္သို႕ ေရးသည့္ လုပ္ငန္းခ်ည္း သက္သက္ အတြက္ O(nmc/p) ၾကာျမင့္မည္။ Sub-query မွ Row ၃ ေသာင္း အေျဖရ၍ Customer Table တြင္ Row ၄ ေသာင္း၊ p သည္ ၄၀၀၀၊ c သည္ ၀.၀၅ စကၠန္႕ ျဖစ္ပါက ပင္မ မွတ္ဥာဏ္ေပၚသို႕ ကူးတင္သည့္ ကိစၥအတြက္ပင္ ၄၀ ၀၀၀ x ၃၀ ၀၀၀၀ x ၀.၀၅ စကၠန္႕ / ၄၀၀၀ = ၁၅၀၀၀ စကၠန္႕ = ၄ နာရီ ၁၀ မိနစ္ (ညတ္ခၽြာျဖား !!!) ၾကာျမင့္မည္။

အဲဒါနဲ႕ ေအာက္ပါ Query နဲ႕ စမ္းၾကည့္ဖုိ႕ စာေရးသူက ေျပာလုိက္ရပါတယ္။

SELECT cust_id, cust_name, cust_add

FROM customer_table

WHERE cust_id IN (SELECT cust_id FROM customer_table

MINUS

SELECT cust_id FROM order_table WHERE ord_type = ‘furniture’);

ခဏနဲ႕ အေျဖရသြားပါသတဲ့။ ဘာမ်ားကြာသြားသလဲ စဥ္းစားၾကည့္ရေအာင္ေနာ္။

ပထမဆံုးအခ်က္က Sub-query ရဲ႕ Results ေသးသြားပါတယ္၊ ဒုတိယအခ်က္ကေတာ့ IN က Customer Table ထဲက cust_id တစ္ခုခ်င္းစီအတြက္ Sub-query Results ထဲမွာ တူတာ တစ္ခုေတြ႕တာနဲ႕ တြက္ခ်က္တာကုိ ရပ္လုိက္လုိ႕ရၿပီး (Short-circuiting လုိ႕ ေခၚပါတယ္) မူလ NOT IN ကေတာ့ Sub-query Results ကုန္ေတာ့မွ ရပ္လုိ႕ရပါတယ္၊ တတိယနဲ႕ ေနာက္ဆံုး အခ်က္ကေတာ့ MINUS က စီၿပီးမွ အလုပ္လုပ္ပါတယ္။ အေသးစိတ္ ရွင္းျပမယ္ေနာ္။

အေပၚက ဥပမာအတုိင္းဆုိလွ်င္ Sub-query မွ ပထမ SELECT Statement ရဲ႕ အေျဖဟာ Row ၄ ေသာင္းရွိၿပီး ဒုတိယ SELECT Statement ရဲ႕ အေျဖဟာ Row ၃ ေသာင္း ရွိပါတယ္။ Referential Integrity Enforcement အရ Order Table ထဲက cust_id ေတြရဲ႕ အစုဟာ Customer Table ထဲက cust_id ေတြရဲ႕ အစုရဲ႕ အစုပုိင္း ျဖစ္တာမုိ႕ Sub-query ရဲ႕ အေျဖက Row ၁ ေသာင္းသာ ရွိေတာ့မွာေပါ့။ ဒါေၾကာင့္ ပင္မ မွတ္ဥာဏ္ထဲကုိ ေရးရသည့္ အခ်ိန္ဟာလဲ ၄၀ ၀၀၀ x ၁၀ ၀၀၀ x ၀.၀၅ စကၠန္႕ / ၄၀၀၀ = ၅၀၀၀ စကၠန္႕ = ၁ နာရီ ၂၄ မိနစ္ေအာက္သာ ရွိေတာ့မွာေပါ့။ အစ္မေတာ္ရဲ႕ ျပႆနာကေတာ့ အေရအတြက္ ကြာတာမုိ႕ မိနစ္ပုိင္းနဲ႕ အေျဖရပါသတဲ့၊ ေကာင္းေလစြ။

Customer Table ထဲက cust_id တစ္ခုခ်င္းစီအတြက္ ပင္မ မွတ္ဥာဏ္ထဲကုိ Sub-query Results ေရးထည့္ၿပီး တူတာရွိ၊ မရွိ တုိက္ၾကည့္ရပါတယ္။ IN ရဲ႕ သေဘာ၊ သဘာ၀က တူတာ တစ္ခု ေတြ႕တာနဲ႕ စစ္တာကုိ ရပ္လုိက္လုိ႕ရပါတယ္။ ပင္မ မွတ္ဥာဏ္ထဲ Sub-query Results အားလံုးကုိ တခ်ိန္ထဲ ထည့္ထားလုိ႕ မရတဲ့အတြက္ p ခုစီ အခါခါထည့္ၿပီး စစ္ေနရာမွာ (p က ၄၀၀၀ ဆုိရင္ Sub-query Results ၁ ေသာင္းကုိ Disk ထဲကေန RAM ေပၚကုိ ၃ ခါခြဲၿပီး ကူးတင္ရပါမယ္။) ရွာေတြ႕သြားရင္ အဲဒီ cust_id အတြက္ ဆက္ထည့္ေပးဖုိ႕ မလုိေတာ့ပါဘူး (ဥပမာ ပထမ ၄၀၀၀ ထဲမွာ ရွာေတြ႕သြားရင္ က်န္တဲ့ ၆၀၀၀ ကုိ RAM ေပၚကုိ ကူးတင္ေပးစရာ မလုိေတာ့ပါဘူး၊ ၂ ခါသက္သာသြားၿပီ)။ ဒါ့အျပင္ ေနာက္ cust_id တစ္ခုအတြက္လဲ လက္ရွိ ထည့္ထားတဲ့ ၄၀၀၀ နဲ႕ ဆက္အလုပ္လုပ္ႏုိင္ပါေသးတယ္ (၃ ခါ သက္သာသြားၿပီ၊ တခါကုိ ၀.၀၅ စကၠန္႕ဆုိေတာ့ ၀.၁၅ စကၠန္႕သက္သာသြားၿပီ)။ NOT IN မွာကေတာ့ အစအဆံုး တုိက္ရတဲ့အတြက္ ဒီလုိလုပ္လုိ႕ မရပါဘူး။

A MINUS B ကုိ တြက္တဲ့အခါမွာ Oracle Database Server က A ကုိ စီ၊ B ကုိ စီၿပီးမွ Sorted File Merging နဲ႕တူတဲ့ နည္းလမ္းစဥ္ကုိ အသံုးျပဳ တြက္ခ်က္တာမုိ႕ စာေရးသူတင္ျပတဲ့ Sub-query ရဲ႕ အခ်ိန္အားျဖင့္ ခက္ခဲမႈ (Time Complexity) ဟာ O(nlog(n) + mlog(m) + m + n) ပဲ ရွိပါတယ္။ (m ႏွင့္ n သည္ Customer Table ရဲ႕ Size ႏွင့္ Order Table မွ မတူညီေသာ cust_id အေရအတြက္တုိ႕ အသီးသီး ျဖစ္သည္။) ဒါေပမဲ့ Customer Table မွာ cust_id ဟာ primary key ျဖစ္လုိ႕ သူ႕ Index ကုိ သံုးမယ္ဆုိရင္ O(mlog(m) + m + n) ပဲ က်န္ပါလိမ့္မယ္။ Cache ရွိမယ္ဆုိရင္ေတာ့ Sub-query ရဲ႕ ကုန္က်စရိတ္ဟာ မရွိသေလာက္ နည္းသြားမွာ ျဖစ္ပါတယ္။

မွတ္ခ်က္ ။ ။ NOT EXISTS ကုိ အသံုးျပဳေရးသားလွ်င္ကား Customer Table မွ cust_id တစ္ခုစီအတြက္ Sub-query တစ္မ်ိဳးစီ တြက္ထုတ္မည္ ျဖစ္သည္။ သုိ႕ရာတြင္ Order Table တြင္ cust_id ျဖင့္ index မရွိႏုိင္ရာ Short-circuiting သံုးႏုိင္ေသာ္လည္း Order Table ကုိ full table scan လုပ္ရမွာပဲ ျဖစ္သည္။ ထုိသုိ႕ဆုိလွ်င္ စာေရးသူ တင္ျပေသာ နည္းလမ္းႏွင့္ ၾကာခ်ိန္တူတူေလာက္ပဲ ျဖစ္မည္။ သုိ႕ရာတြင္ Database Server မ်ားတြင္ Query Results မ်ားကုိ Cache လုပ္ထားတတ္ရာ cust_id တစ္ခုစီအတြက္ Sub-query တစ္မ်ိဳးစီ တြက္ထုတ္ေနသာ နည္းလမ္းသည္ အၿမဲ Cache Miss ျဖစ္ေနၿပီး Sub-query တစ္မ်ိဳးတည္းသာရွိေသာ စာေရးသူ တင္ျပသည့္ နည္းလမ္းမွာကား Cache ကို အက်ိဳးရွိစြာ အသံုးခ်ႏုိင္သျဖင့္ စာေရးသူ တင္ျပေသာ နည္းလမ္းက ပုိမုိေကာင္းမြန္သည္ဟု ဆုိႏုိင္သည္။

Database နည္းပညာဟာ အလုပ္လုပ္ပံု အေသးစိတ္ကို သံုးစြဲသူ ေခါင္းမရႈပ္ရေအာင္ ၀ွက္ထားေပးတယ္ဆုိေပမဲ့ တခါတေလမွာ သူ႕ရဲ႕ Statistics နဲ႕ Query Optimizer Algorithm ဟာ သံုးစြဲသူရဲ႕ Knowledge ကုိ မယွဥ္ႏုိင္တာကုိ ေတြ႕ရပါတယ္။ ဒါေၾကာင့္ သင့္ရဲ႕ Query ကုိ Execute ရာမွာ လိုတာထက္ ပုိၾကာေနၿပီဆုိရင္ သင့္အေနနဲ႕ ၀င္ပါရေတာ့မွာ ျဖစ္ပါတယ္။ System Level Optimization, DBA Level Optimization စတာေတြကို အသံုးျပဳသူတုိင္း ေဆာင္ရြက္ခြင့္ မရၾကပါဘူး။ အဲဒီအခါမ်ိဳးမွာ Query Optimizer ရဲ႕ Query Plan Formulation Logic နဲ႕ အေျခခံ နည္းလမ္းစဥ္ သရုပ္ခြဲပညာတုိ႕နဲ႕ ယဥ္ပါးတဲ့ သံုးစြဲသူမ်ားအေနနဲ႕ အထက္ေဖာ္ျပပါကဲ့သုိ႕ SQL Statement Level Optimization မ်ားကို ေဆာင္ရြက္ႏုိင္ေၾကာင္း တင္ျပလုိက္ရပါသည္။

http://download.oracle.com/docs/html/A86647_01/vmqtune.htm#1004143 ကုိမွီျငမ္းပါသည္။

လူကိုလူလို ေလးစားျခင္းဟာ ယဥ္ေက်းမႈ

၂၀၁၀ ခု ဧျပီလ ၇ ရက္ေန့ထုတ္ Weekly Eleven News Journal ပါ လူထုစိန္၀င္း၏ လူကိုလူလို ေလးစားျခင္းဟာ ယဥ္ေက်းမႈ ေဆာင္းပါး (www.crystalrays.org တြင္ ringo က ရုိက္တင္ေပးထားေသာ စာမူ) သည္ ေလာရွည္ - ကတဲ့ပြဲ၏ မူႏွင့္ ကုိက္ညီသျဖင့္ မူရင္းအာေဘာ္အတုိင္း ျပန္လည္ ေဖာ္ျပအပ္ပါသည္။ 

မူရင္းေရးသားသူထံ သီးသန့္ခြင့္ျပဳခ်က္ေတာင္းခံရန္ အခက္အခဲရွိပါသျဖင့္ ခြင့္ျပဳခ်က္ မေတာင္းခံပဲ ေဖာ္ျပျခင္းျဖစ္သည္။ မူရင္းေရးသားသူက ပယ္ဖ်က္ေပးပါရန္ ေတာင္းဆုိပါက အခ်ိန္မဆုိင္းပဲ ခ်က္ခ်င္း ပယ္ဖ်က္ေပးမည္။

စာနယ္ဇင္းေတြ ဖတ္ရင္းနဲ႔ အနယ္နယ္ အရပ္ရပ္မွာ စာေပေဟာေျပာပြဲနဲ႔ စာေပေဆြးေႏြး၀ိုင္းေတြ လုပ္ၾကတဲ့သတင္းေတြ မျပတ္ေတြ႔ေနရတယ္။ ဟိုေရွးကေတာ့ နတ္ေတာ္လဆန္း တစ္ရက္ေန႔ တစ္ရက္တည္းပဲ စာေပေဟာေျပာပြဲနဲ႔ စာဆိုေတာ္ေန႔ က်င္းပၾကတယ္။ ေနာက္ေတာ့ မႏၲေလးက ဦးေလးလူထုဦးလွက နတ္ေတာ္လ တစ္လလံုးကို စာဆိုေတာ္လလို႔ သတ္မွတ္ၿပီး စာေပေဟာေျပာပြဲေတြ လုပ္ၾကပါလို႔ စတင္လံႈ႕ေဆာ္ခဲ့တာေၾကာင့္ စာဆိုေတာ္ေန႔ ေက်ာ္လြန္သြားလည္း ေဟာေျပာပြဲေတြ ဆက္လုပ္ၾကတယ္။

ဆရာေတြ ေဖာင္းပြေန

အခုေတာ့ နတ္ေတာ္လ တစ္လတည္းသာ မကေတာ့ဘူး။ တစ္ႏွစ္ပတ္လံုး စာေပေဟာေျပာပြဲေတြ၊ ေဆြးေႏြးပြဲေတြ ေတာေရာၿမိဳ႕ပါမက်န္ က်င္းပေနၾကတာကို ၀မ္းသာစရာ ေတြ႔ရတယ္။ ဦးေလးလွသာရွိရင္ သိပ္၀မ္းသာမွာ။ စာေပလႈပ္ရွားမႈ သတင္းမွန္သမွ် မလြတ္တမ္းဖတ္ရင္းနဲ႔ သတိထားမိတာေလးတစ္ခု ရွိပါတယ္။ နယ္တစ္နယ္မွာ စာေပလႈပ္ရွားမႈတစ္ခု လုပ္တဲ့သတင္းကို ေရးၾကရာမွာ ဥကၠ႒ ဆရာေမာင္ဘယ္သူက သဘာပတိလုပ္ၿပီး အတြင္းေရးမွဴး ဆရာေမာင္ဘယ္၀ါက အခမ္းအနားမွဴး လုပ္တယ္။ ဆရာေမာင္ျဖဴ၊ ဆရာေမာင္နီ၊ ဆရာေမာင္နက္၊ ဆရာေမာင္ျပာ၊ ဆရာေမာင္၀ါ၊ ဆရာေမာင္ညိဳ၊ ဆရာေမာင္စိမ္းတို႔က စာတမ္းဖတ္ၾက၊ ေဆြးေႏြးၾကတယ္။ ဆရာေမာင္ခရမ္းေရာင္နဲ႔ ဆရာေမာင္ပန္းေရာင္တို႔က ကဗ်ာ႐ြတ္ၾကတယ္ စတဲ့ အေရးအသားမ်ဳိးေတြကိုခ်ည္း ေတြ႔ရတယ္။ သတင္းတစ္ပုဒ္အေနနဲ႔ "လိုတိုရွင္း" မျဖစ္သလို၊ ဆရာဆိုတဲ့ အသံုးအႏႈန္းကလည္း ေဖာင္းပြေနသလို ထင္မိတယ္။

ေျခသည္းလွီးတဲ့ ဆရာကေတာ္

ေျပာရတာ အားနာပါတယ္။ ကိုယ္က စာဖတ္မႏွံ႔စပ္ေတာ့ ေဖာ္ျပထားတဲ့နာမည္ေတြ အားလံုးေလာက္နီးပါးဟာ ကိုယ္မၾကားဖူးတဲ့ နာမည္ေတြခ်ည္း ျဖစ္ေနတတ္တယ္။ ေရွ႕ေလွ်ာက္ ႀကိဳးစားၿပီး စာကိုႏွံ႔စပ္ေအာင္ ဖတ္မွျဖစ္ေတာ့မယ္လို႔ ကိုယ့္ကိုယ္ကိုယ္ သတိေပးရတယ္။ တစ္ဆက္တည္း ေျပာခ်င္တာေလးတစ္ခု ႀကံဳတုန္း ေျပာလိုက္ပါဦးမယ္။ ကြၽန္ေတာ္တို႔ ျမန္မာလူမ်ဳိးမ်ားက ယဥ္ေက်းလြန္းတာလား၊ နိ၀ါတတရား ထားလြန္းတာလားေတာ့ မသိဘူး။ ဆရာအေခၚ သိပ္ကို ရက္ေရာလြန္းတယ္လို႔ စိတ္ထဲစြဲထင္ေနတဲ့ အေၾကာင္းပါ။ ကားဆရာ၊ ဆိုက္ကားဆရာ၊ ပန္းရံဆရာ၊ လက္သမားဆရာ၊ ဆံပင္ညႇပ္ဆရာ စသျဖင့္ လူေတြ႔တိုင္း ဆရာေခၚတာ အက်င့္ႀကီးတစ္ခုလို ျဖစ္ေနပါၿပီ။ ကြၽန္ေတာ္တို႔ငယ္ငယ္က မႏၲေလးမွာ ရပ္ကြက္ထဲလွည့္ၿပီး ေျခသည္းလက္သည္းလွီး၊ နဖာကေလာ္လုပ္တဲ့ ပုေဏၰးမေတြ ရွိပါတယ္။ သူတို႔ကို ဘာေၾကာင့္မွန္းမသိ "ဆရာကေတာ္" လို႔ ေခၚၾကတယ္။

သခင္ေခၚရာက ကူးစက္တာလား

အသက္ႀကီးလာေတာ့ သူမ်ားေတြက "ဆရာကေတာ္၊ ဆရာကေတာ္"နဲ႔ ေခၚတာၾကားတိုင္း ေျခသည္းလွီးတဲ့ ဆရာကေတာ္ေတြကို မ်က္စိထဲျမင္ၿပီး က်ိတ္ၿပံဳးမိတာခ်ည္းပါပဲ။ လူေတြ႔တိုင္း ဆရာေခၚတဲ့အက်င့္ဟာ ေရွးပေ၀သဏီကတည္းက ရွိခဲ့တဲ့ ျမန္မာ့ယဥ္ေက်းမႈလား၊ သူ႔ကြၽန္ဘ၀မွာ မ်က္ႏွာျဖဴေတြကို သခင္ေခၚရာက ကူးစက္သြားတာလား၊ ဖက္ဆစ္ေတြကို မာစတာေခၚရာက ႏႈတ္အက်င့္ ျဖစ္သြားတာလား ေသေသခ်ာခ်ာ ေလ့လာၾကည့္ဖို႔ေတာ့ ေကာင္းတယ္။ ဆရာ၊ ဆရာနဲ႔ ေျပာၾကေရးၾက တာေတြေတြ႔တိုင္း စိတ္ထဲမွာ ဘ၀င္မက် ျဖစ္မိတယ္။ ေကာင္းတဲ့အက်င့္တစ္ခုေတာ့ မဟုတ္ဘူးလို႔လည္း စိတ္မွာထင္မိတယ္။

ေသြးနထင္ေရာက္ ျဖစ္တတ္တယ္

အခ်က္ႏွစ္ခ်က္ေပၚ မူတည္ၿပီး ေကာင္းတဲ့အက်င့္ မဟုတ္ဘူးလုိ႔ ထင္တာပါ။ ပထမအခ်က္ကေတာ့ ဆရာ၊ ဆရာနဲ႔ အေခၚခံရပါမ်ားေတာ့ အေခၚခံရသူဟာ အလုိလိုေနရင္း ေသြးနထင္ေရာက္ၿပီး ေျမာက္ႂကြေျမာက္ႂကြ ျဖစ္သြားတတ္ပါတယ္။ ႐ံုးတစ္႐ံုးကို ကိစၥရွိလို႔ သြားတဲ့အခါ ေတြ႔တဲ့ျပာတာကုိျဖစ္ျဖစ္၊ စာေရးေလးကုိျဖစ္ျဖစ္၊ မ်က္ႏွာခ်ဳိေသြးၿပီး ဆရာ၊ ဆရာနဲ႔ ဆရာခ်င္းထပ္ေအာင္ ေခၚတဲ့အခါက်ေတာ့ ပင္ကို႐ိုးသားတဲ့လူေတာင္ ဆရာဆိုတဲ့ အေခၚနဲ႔လိုက္ေအာင္ အာဏာပါ၀ါ ျပခ်င္တဲ့စိတ္ေတြ ၀င္လာၿပီး ဟိန္းတာေဟာက္တာေတြ လုပ္တတ္သြားပါတယ္။ ေဆး႐ံုေပါက္ေစာင့္တဲ့ ဒရ၀မ္ေတာင္ ခပ္တည္တည္နဲ႔ ရင္ေကာ့ၿပီး တံခါး၀မွာ ရပ္လိုက္ရင္ အလိုလုိရွိန္ၿပီး ႐ို႐ိုက်ဳိးက်ဳိးနဲ႔ တံခါးဖြင့္ေပးေလ့ ရွိပါတယ္။ ေၾကာက္သလိုလို၊ ႐ြံ႕သလိုလိုနဲ႔ သူ႔ကုိ ဆရာေခၚၿပီး ၀င္ပါရေစလို႔ သြားေျပာရင္ေတာ့ "ဒါလူနာေတြ႔ခ်ိန္ မဟုတ္ဘူး" ဆိုၿပီး မာန္မဲလႊတ္လိုက္မွာ ေသခ်ာတယ္။ ထပ္ၿပီး မ်က္ႏွာငယ္ေလးနဲ႔ ေတာင္းပန္ရင္လည္း "ဆရာ၀န္ႀကီး ေရာင္းလွည့္ေနတယ္၊ ဘယ္သူမ ွမ၀င္ရဘူး" လို႔ ေဟာက္ဦးမွာပါပဲ။

ကၽြန္စိတ္

လူေတြ႔တုိင္း ဆရာေခၚတဲ့အက်င့္ ျဖစ္ေနသူနဲ႔ ပတ္သက္တာက ဒုတိယအခ်က္ပါ။ ေဆး႐ံုက ဒရ၀မ္ကုိေတာင္ ဆရာေခၚတဲ့အက်င့္ ျဖစ္ေနသူဟာ ဘယ္သူ႔ေတြ႔ေတြ႔ ဆရာေခၚလိုက္မွာပဲ။ ၾကာရင္ လူတိုင္းဟာ ေၾကာက္ရမယ့္လူ၊ "ခယ၀ယ" လုပ္ရမယ့္လူလုိ႔ခ်ည္း ထင္မွတ္ၿပီး အလိုလုိေနရင္း "သိမ္ငယ္စိတ္" (inferiority complex)ေတြ ၀င္လာတတ္ပါတယ္။ သိမ္ငယ္စိတ္ ၀င္လာတာနဲ႔တစ္ၿပိဳင္နက္ ကုိယ္ရည္ကုိယ္ေသြး၊ ကုိယ္စြမ္းကုိယ္စေတြပါ အလုိလို က်ဆင္းသြားေလ့ ရွိပါတယ္။ ကြၽန္စိတ္ဆိုတာ သိမ္ငယ္စိတ္က ေပါက္ဖြားလာတာ ျဖစ္ပါတယ္။

သခင္စိတ္

နယ္ခ်ဲ႕လက္ေအာက္မွာ ကြၽန္သေပါက္ဘ၀နဲ႔ သားစဥ္ေျမးဆက္ ႏွစ္ေပါင္းရာေက်ာ္ ေနခဲ့ရေလေတာ့ လူေတြမွာ အနည္းနဲ႔အမ်ား ဆိုသလုိ ကြၽန္စိတ္ေတြ ရွိေနၾကတယ္။ အဲဒါေၾကာင့္ တို႔ဗမာအစည္းအ႐ံုးေခတ္မွာ၊ ျမန္မာဆိုတာ ကြၽန္လူမ်ဳိး မဟုတ္ဘူး။ ကိုယ့္ထီးကုိယ့္နန္း ကုိယ့္ၾကငွန္းနဲ႔ အဆင့္ျမင့္တဲ့ ကုိယ္ပုိင္ယဥ္ေက်းမႈနဲ႔ ေနခဲ့ၾကတဲ့ သခင္လူမ်ဳိး ျဖစ္တယ္ဆိုတာကုိ သတိေပးဖို႔အတြက္ အဖြဲ႔၀င္တုိင္းရဲ႕ နာမည္ေရွ႕မွာ "သခင္" တပ္ၿပီး၊ သခင္ႏု၊ သခင္ေအာင္ဆန္း၊ သခင္ဗဟိန္း၊ သခင္သန္းထြန္းလို႔ ေခၚခဲ့ၾကတာ ျဖစ္တယ္။ "မင္းတို႔ဆရာကိုေလ၊ စာရင္းတုိ႔ကာသာ ထားလိုက္ေပေတာ့" လို႔ ဆိုခဲ့တဲ့ ဆရာႀကီးဦးလြန္းေတာင္ တပည့္ေတြ ဆင္ႏႊဲတဲ့ တုိက္ပြဲတိုင္း ေရွ႕ကမားမားမတ္မတ္နဲ႔ ပါၿမဲျဖစ္တဲ့အတုိင္း "သခင္ကုိယ္ေတာ္မိႈင္း" ျဖစ္သြားခဲ့ရပါတယ္။

ဇြတ္႐ိုက္မသြင္းသင့္

ယဥ္ေက်းတယ္ဆိုတာ အင္မတန္ လိုလားအပ္တဲ့အရာ ျဖစ္တယ္။ လူအေတာ္မ်ားမ်ားက ေအာက္က်ဳိ႕တာ၊ ႏွိမ့္ခ်တာကုိ ယဥ္ေက်းမႈလို႔ ထင္မွတ္မွားေနၾကၿပီး၊ ေအာက္က်ဳိ႕ႏွိမ့္ခ်စိတ္ထားဖို႔ သြန္သင္ဆံုးမေလ့ ရွိၾကတယ္။ "လူ႔ေအာက္က်ဳိ႕လို႔ မေသပါဘူး" ဆိုတဲ့ ဆို႐ိုးစကားေတာင္ ရွိခဲ့တယ္။ ေအာက္က်ဳိ႕လြန္း၊ ႏွိမ့္ခ်လြန္းတဲ့ စိတ္ကေနၿပီး "ကြၽန္စိတ္" ေပါက္ဖြားလာရတာလို႔ ယံုၾကည္တဲ့အတြက္ သေဘာမက်ပါဘူး။ ပလႊား၀င့္၀ါ မရွိတာ၊ ေမာက္မာေစာ္ကား မရွိတာ အင္မတန္ ေကာင္းတယ္။ ဒါမ်ဳိးကုိ အားေပးရမွာ။ ဒီစိတ္ဓာတ္မ်ဳိး ေမြးရမွာ။ ေအာက္က်ဳိ႕တာ၊ ႏွိမ့္ခ်တာေတာ့ အားမေပးသင့္ဘူး။ ကေလးေတြေခါင္းထဲ ဇြတ္႐ိုက္မသြင္းသင့္ဘူး။

ထိုက္တန္တဲ့ ေလးစားမႈ

လူယဥ္ေက်းဆုိတာ တစ္ဖက္သားကုိ လူတစ္ေယာက္အေနနဲ႔ တန္ဖိုးထား ေလးစားတတ္ျခင္းကုိ ေခၚတာျဖစ္တယ္။ တစ္ဖက္သားရဲ႕ အေပၚယံ ပကာသန အေဆာင္အေယာင္ေတြကုိ ၾကည့္ၿပီး "ခယ၀ပ္တြား" ဆက္ဆံတာကုိ ေခၚတာမဟုတ္ဘူး။ ျပာတာပဲျဖစ္ျဖစ္၊ ဆုိက္ကားသမားပဲျဖစ္ျဖစ္၊ ယုတ္စြအဆံုး သူေတာင္းစားပဲျဖစ္ျဖစ္၊ လူသားအေနနဲ႔ ၾကည့္ျမင္ၿပီး၊ လူသားအေနနဲ႔ ထိုက္သင့္တဲ့အေလ်ာက္ ေလးစားမႈေပး ဆက္ဆံတာဟာ ယဥ္ေက်းျခင္း ျဖစ္တယ္။ ဘယ္သူ႔ကုိမဆုိ ေအာက္က်ဳိ႕ႏွိမ့္ခ်ၿပီး ဆက္ဆံဖို႔ မလိုဘူး။ ထုိက္တန္တဲ့ ေလးစားမႈေပးဖို႔သာ လိုတယ္။

ဆင္းရဲရင္ မကန္ေတာ့ခ်င္

မွန္တာေျပာရရင္ လူအခ်င္းခ်င္း လူလို႔ျမင္ၿပီး ေလးေလးစားစား တန္ဖိုးထားတာမ်ဳိး ေတြ႔ရခဲတယ္။ ပိုက္ဆံေငြေၾကးလို၊ ရာထူးအာဏာလို၊ အေပၚယံ ပကာသနေတြကုိၾကည့္ၿပီး ဆက္ဆံၾကတာပဲ အေတြ႔ရမ်ားတယ္။ ေသြးမေတာ္၊ သားမစပ္တဲ့ ေငြရွိသူ၊ ဂုဏ္ျဒပ္နဲ႔ ရာထူးအာဏာရွိသူကုိ အခါႀကီးရက္ႀကီးေရာက္တိုင္း မေမ့မေလ်ာ့ ႏွစ္စဥ္ယဥ္ေက်းမႈ အရဆိုၿပီး သြားကန္ေတာ့တတ္ၾကေပမယ့္ ေငြမရွိ၊ ရာထူးအာဏာမရွိ ဆင္းရဲမြဲေတတဲ့ ေဆြမ်ဳိးရင္းခ်ာမ်ားကုိေတာ့ ကန္ေတာ့ဖို႔ ေမ့ေလ်ာ့ေနတတ္ၾကတာ မ်ားတယ္။ ယဥ္ေက်းမႈဆိုတာ လူအခ်င္းခ်င္း လူလိုျမင္ၿပီး လူလိုေလးစား တန္ဖိုးထားတတ္ျခင္းကုိ ေခၚတာျဖစ္ပါတယ္။ အဲဒီလုိယဥ္ေက်းမႈ ထြန္းကားေစဖို႔ကုိပဲ ေမွ်ာ္လင့္ရပါတယ္။

လူထုစိန္၀င္း

ေလာရွည္ မွတ္ခ်က္ ။ ။ ၀န္ေဆာင္မႈ လုပ္ငန္းမ်ား (ဟုိတယ္၊ စားေသာက္ဆုိင္၊ သယ္ယူပုိ႔ေဆာင္ေရး စသည္) မွာေတာ့ သခင္စိတ္အသြင္းလြန္ၿပီး နင္လဲလူ၊ ငါလဲလူ  မသိဘူး၊ မရွိဘူး၊ ကုန္ၿပီဆုိၿပီး ဘုမေတာမိေစဖုိ႔ အေရးႀကီးလွပါတယ္။