નાની ક્વેરી પરત આવે છે, મોટી અટકી જાય છે અથવા પડી જાય છે, અને પ્રથમ અનુમાન એ છે કે પેકેટના કદમાં કંઈક ખોટું છે. તે અનુમાન સામાન્ય રીતે સાચું હોય છે અને લગભગ હંમેશા ખોટા સ્તર પર લક્ષ્ય રાખે છે. ત્રણ સેટિંગ પેકેટ શબ્દ વહેંચે છે અને ત્રણ અસંબંધિત વસ્તુઓ માપે છે: ડેટાબેઝ ડ્રાઇવરનું પરિવહન પેકેજિંગ, ડેટાબેઝ સર્વરની સંદેશ મર્યાદા અને IP માર્ગનું મહત્તમ પ્રસારણ એકમ. એકને સમાયોજિત કરીને બીજાથી થયેલા લક્ષણને ઠીક કરવો એ પાંચ મિનિટની સમસ્યાને એક અઠવાડિયાના ટ્યુનિંગમાં ફેરવવાનો રસ્તો છે. નીચેનો ક્રમ એ છે જેણે મને સૌથી ઓછો સમય લીધો.

ત્રણ સ્તર, એક સામાન્ય શબ્દ

નીચેની દરેક પંક્તિ અલગ માલિક સાથેનું અલગ એકમ છે, અને તેમાંથી કોઈના વિશે બીજા પરથી તર્ક કરી શકાતો નથી. ડેટાબેઝ સંદેશ ઘણા TCP સેગમેન્ટ અને ઘણા IP પેકેટ સુધી ફેલાઈ શકે છે, તેથી તેનું માન્ય કદ વધારવાથી માર્ગ પહોળો થતો નથી, અને ડ્રાઇવર સેટિંગ ઘટાડવું એ ઇન્ટરફેસ MTU બદલવાની સમાન ક્રિયા નથી. શબ્દ ત્રણ અલગ કન્ફિગરેશન ફાઇલોમાં દેખાય છે, તેથી તેને શોધવાથી ત્રણ અસંબંધિત જવાબો મળે છે. પહેલા ભૂલનું લખાણ વાંચો, પછી નક્કી કરો કઈ ફાઇલ ખોલવી.

Setting or observationUnit it describes
SQL Server client network packet settingThe provider's transport packaging for that connection
MySQL communication packet limitA database message, such as one statement, row or replication event
IP path MTUThe largest IP packet the path carries without fragmentation handling

કન્ફિગરેશન ફાઇલ ખોલતા પહેલા લખો કે નિષ્ફળ ક્રિયા કયા સ્તરની છે. ભૂલનું લખાણ સામાન્ય રીતે તે કહે છે, અને ભૂલનું લખાણ એ જ ભાગ છે જે લોકો છોડી દે છે.

તેનું સેટિંગ બદલતા પહેલા પ્રદાતાને ઓળખો

SQL Server માટે, એપ્લિકેશન, ડ્રાઇવર અથવા પ્રદાતાનું નામ, આવૃત્તિ અને અસરકારક કનેક્શન કન્ફિગરેશન નોંધો. ડાયગ્નોસ્ટિક સ્ક્રિપ્ટ અને ડેસ્કટોપ એપ્લિકેશન અલગ પ્રદાતાઓ દ્વારા એક જ સર્વર સુધી પહોંચી શકે છે, તેથી એકને મદદ કરતું સેટિંગ બીજા વિશે કંઈ સાબિત કરતું નથી. પ્રદાતાઓના ડિફોલ્ટ અલગ હોય છે, અને સમાન નામનું કનેક્શન-સ્ટ્રિંગ ફીલ્ડ એ પુરાવો નથી કે દરેક પ્રદાતા તેને એક જ રીતે અર્થઘટન કરે છે.

ફક્ત એટલા માટે જૂનું ઉપાય તેની સિન્ટેક્સ વાપરતું હતું તે કારણે સંભાળાયેલા ડ્રાઇવરને જૂના સાથે બદલશો નહીં. વર્તમાન દસ્તાવેજીકરણ તે જૂના ઘટકો પર નવા વિકાસને નિરુત્સાહિત કરે છે, અને તેમની મર્યાદાઓ વારસામાં લેવી એક સેટિંગ માટે ખરાબ સોદો છે.

સંદેશનો અસ્વીકાર માર્ગનો અટકાવ નથી

MySQL 8.4 માં, સંચાર-પેકેટ દસ્તાવેજીકરણ વર્ણવે છે કે ખૂબ મોટું સ્ટેટમેન્ટ, પંક્તિ અથવા બાઇનરી-લોગ ઘટના લાગુ મર્યાદા સામે અસ્વીકાર પામે છે, અને ક્લાયન્ટ અને સર્વર બંનેની મર્યાદા મહત્વપૂર્ણ હોઈ શકે છે. તે ડેટાબેઝ સ્તરે અસ્વીકાર છે, એવું નિવેદન નથી કે નેટવર્કે વિશાળ IP પેકેટ વહન કરવું પડે. વાસ્તવિક ભૂલ અને ગેરવર્તન કરતા સંદેશનો આકાર વાંચો: ઘણી નાની પંક્તિઓનું મોટું પરિણામ એક વિશાળ પંક્તિ કરતાં અલગ કિસ્સો છે, અને તે અલગ રીતે નિષ્ફળ જાય છે.

MariaDB ઇન્સ્ટોલેશનને તેમના પોતાના આવૃત્તિની દસ્તાવેજી મર્યાદા અને નિદાનની જરૂર છે. MySQL ના ડિફોલ્ટ MariaDB પર કોપી કરવા એ વધારાના પગલાં સાથે અનુમાન કરવું છે.

માર્ગનો પુરાવો ખરેખર કેવો દેખાય છે

માર્ગ-કદની સમસ્યાની પોતાની આંગળીની છાપ છે: ચોક્કસ માર્ગ અને સરનામા-કુટુંબ પર પુનરાવર્તનીય કદ-આધારિત પરિવહન નિષ્ફળતા, જેમાં ટનલનો વધારાનો ભાર સામેલ હોય અને શોધ-પ્રતિસાદ માર્ગ જે પરવાનગી આપે તેમ વર્તે. એકલો ટાઇમઆઉટ તેને ધીમી ક્વેરી, ડ્રાઇવર બગ અથવા સર્વર-બાજુની મર્યાદાથી અલગ પાડતો નથી, અને ટાઇમઆઉટને MTU સમસ્યાના પુરાવા તરીકે ગણવો તમને આત્મવિશ્વાસ સાથે ખોટા સ્તર પર મોકલે છે.

જો તમે માર્ગ પરીક્ષણ કરો, તો લક્ષ્ય, ખાતું અને કાર્યભાર સ્થિર રાખો જેથી એકમાત્ર ચલ તમે તપાસો છો તે કદ હોય. જે પરીક્ષણમાં ત્રણ વસ્તુઓ બદલાઈ તે તમને કઈ વસ્તુ મહત્વની હતી તે વિશે કંઈ કહેતું નથી.

એક દસ્તાવેજી ચલ બદલો, પછી તેને નોંધો

લક્ષ્ય, ખાતું, પ્રદાતા અને કાર્યભાર સ્થિર રાખો, મૂળ મૂલ્ય નોંધો, એક સમર્થિત ફેરફાર લાગુ કરો અને પરિણામ નોંધો. નાનું સેટિંગ જે એક પરીક્ષણ પાસ કરાવે છે તે તે પરીક્ષિત સ્ટેક વિશે ઉપયોગી પુરાવો છે; તે સાર્વત્રિક શ્રેષ્ઠ નથી અને મૂળ નિષ્ફળતાનું કારણ સ્થાપિત કરતું નથી. આ અલગ દાવાઓ છે, અને ફક્ત પ્રથમને એક પ્રયોગ દ્વારા સમર્થન મળે છે.

ઓળખાયેલી મર્યાદાને તેના પોતાના સ્તરે ઉકેલો, પછી નોંધો કે તે કયું સ્તર હતું. તે નોંધ જ આગલી વ્યક્તિને ડ્રાઇવર ટ્યુન કરતા રોકે છે કારણ કે સમસ્યા માર્ગમાં હતી.

સંબંધિત લેખો