คำถามติดแท็ก performance

การประเมินว่าระบบทำงานได้ดีพอที่จะเหมาะสมกับวัตถุประสงค์หรือไม่ โดยทั่วไปแล้วประสิทธิภาพหมายถึงความเร็วที่ระบบดำเนินการเสร็จสิ้นหรือชุดของการดำเนินงานเมื่อเวลาผ่านไป

2
การแสดงแผนการดำเนินการโดยประมาณจะสร้าง CXPACKET, PAGELATCH_SH และ LATCH_EX [ACCESS_METHODS_DATASET_PARENT] รอ
ผมใช้ Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) ใน 4 vCPU VM กับmax degree of parallelismชุด2และชุดcost threshold for parallelism50 ในตอนเช้าเมื่อพยายามแสดงแผนการดำเนินการโดยประมาณสำหรับคิวรีแบบเลือก TOP 100ฉันพบว่าต้องรอเป็นจำนวนมากและการดำเนินการเพื่อแสดงแผนโดยประมาณใช้เวลาไม่กี่นาทีบ่อยครั้งในช่วง 5 - 7 นาที อีกครั้งนี้ไม่ได้ปฏิบัติจริงของแบบสอบถามนี้เป็นเพียงกระบวนการเพื่อแสดงแผนการดำเนินการโดยประมาณ sp_WhoIsActiveจะแสดงPAGEIOLATCH_SHรอหรือLATCH_EX [ACCESS_METHODS_DATASET_PARENT]รอและเมื่อฉันเรียกใช้สคริปต์WaitingTasks.sql ของ Paul Randalในระหว่างการดำเนินการก็จะแสดงการCXPACKETรอด้วยเธรดผู้ทำงานที่แสดงการPAGEIOLATCH_SHรอ: * ฟิลด์คำอธิบายทรัพยากร = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen เธรดผู้ปฏิบัติงานดูเหมือนจะนำstatsตารางทั้งหมดมาไว้ในหน่วยความจำ (เช่นหมายเลขหน้าเหล่านั้นรวมถึงหมายเลขหน้าถัดไปที่แสดงจากแบบสอบถามของ Paul Randal กลับไปยังคีย์คลัสเตอร์สำหรับstatsตาราง) เมื่อแผนกลับมามันเป็นช่วงเวลาที่เหลือของวันทันทีหลังจากที่ฉันเห็นการstatsขัดสีส่วนใหญ่ของตารางจากแคชที่มีเพียงระเบียนต่าง ๆ ที่เหลืออยู่เท่านั้น …

2
ทำไมคำขอ Batch ของฉันเพิ่มขึ้นเมื่อทำการสำรองข้อมูลต่าง
ฉันเริ่มทำการติดตามระยะยาวของกิจกรรมต่าง ๆ ใน SQL Server 2012 ของเราและฉันสังเกตเห็นการเพิ่มของคำขอ Batch ในระหว่างการสำรองข้อมูลที่เพิ่มขึ้นของเรา เพื่อให้ความคิดปกติวันต่อวันเราอยู่ที่ประมาณ 10-20 ชุดคำขอต่อวินาที แต่ในช่วงเวลาที่การสำรองข้อมูลที่แตกต่างกันของเรามันกระโดดไปที่ 100-130 ต่อวินาที ฉันรู้ว่ามันไม่มาก แต่ก็ทำให้ฉันอยากรู้ว่าสิ่งที่เกิดขึ้นนั้นเพิ่มขึ้น 10 เท่า ไม่แน่ใจว่าข้อมูลใดที่คุณอาจต้องใช้เพื่อช่วยแก้ไขปัญหานี้

3
CXPACKET สูงและ LATCH_EX กำลังรอ
ฉันมีปัญหาด้านประสิทธิภาพกับระบบประมวลผลข้อมูลที่ฉันกำลังทำงานอยู่ ฉันได้รวบรวมสถิติการรอจากเวลาหนึ่งชั่วโมงที่แสดง CXPACKET และ LATCH_EX รอเหตุการณ์จำนวนมาก ระบบประกอบด้วยการประมวลผล SQL เซิร์ฟเวอร์ 3 เครื่องซึ่งมีจำนวนการกระทืบและการคำนวณจำนวนมากจากนั้นป้อนข้อมูลลงในเซิร์ฟเวอร์คลัสเตอร์กลาง เซิร์ฟเวอร์ประมวลผลสามารถมีงานได้ถึง 6 งานในแต่ละครั้ง สถิติการรอเหล่านี้มีไว้สำหรับคลัสเตอร์กลางซึ่งฉันคิดว่าเป็นสาเหตุของปัญหาคอขวด เซิร์ฟเวอร์คลัสเตอร์ส่วนกลางมี 16 คอร์และ 64GB RAM MAXDOP ถูกตั้งค่าเป็น 0 ฉันเดาว่า CXPACKET นั้นมาจากการสืบค้นหลายขนานที่ทำงานอยู่ แต่ฉันไม่แน่ใจว่าสิ่งที่ LATCH_EX รอเหตุการณ์ระบุไว้ จากสิ่งที่ฉันได้อ่านนี้อาจเป็นการรอแบบไม่บัฟเฟอร์? ทุกคนสามารถแนะนำสาเหตุของการรอคอยสถิติเหล่านี้ได้อย่างไรและฉันควรดำเนินการอย่างไรเพื่อตรวจสอบสาเหตุที่แท้จริงของปัญหาประสิทธิภาพการทำงานนี้ ผลลัพธ์ข้อความค้นหายอดนิยมคือสถิติการรอคอยทั้งหมดและผลลัพธ์ข้อความค้นหาด้านล่างคือสถิติในช่วงเวลา 1 ชั่วโมง

2
แกน CPU เพิ่มเติมเทียบกับดิสก์ที่เร็วกว่า
ฉันเป็นส่วนหนึ่งของ บริษัท ขนาดเล็กดังนั้นตามปกติจะครอบคลุมบทบาทที่แตกต่างกันจำนวนหนึ่ง ล่าสุดคือการจัดหากล่อง SQL Server เฉพาะสำหรับ. NET web app ของเรา เราได้รับการยกมาใน Dual Xeon E5-2620 (หกคอร์) การกำหนดค่าซีพียู 2.00 GHz (รวม 12 คอร์) พร้อม RAM 32 GB สิ่งนี้ทำให้เรามีงบประมาณ จำกัด สำหรับดิสก์อาเรย์ซึ่งโดยพื้นฐานแล้วจะประกอบด้วยไดรฟ์ SAS 300 GB 2.5 นิ้ว (15k RPM) สองตัวในการกำหนดค่า RAID 1 ฉันรู้ว่าการตั้งค่าดิสก์นั้นเหมาะสมที่สุดสำหรับ SQL Server และฉันต้องการผลักดัน RAID 10 จริงๆเพื่อให้เราสามารถวางฐานข้อมูลไฟล์บันทึกและ tempdb ลงในไดรฟ์ของตัวเอง เพื่อที่จะทำให้มันเข้ากันได้กับงบประมาณของเราฉันควรพิจารณาลดจำนวนคอร์ของ CPU …

1
ข้อใดดีกว่า: หลายเงื่อนไขเข้าร่วมหรือหลายเงื่อนไข
ฉันพยายามที่จะเปรียบเทียบคำถามที่สอง: แบบสอบถาม 1: SELECT a,b,c,d,e FROM tableA LEFT JOIN tableB ON tableA.a=tableB.a WHERE tableA.b=tableB.b AND tableA.c=tableB.c AND tableA.d=tableB.d AND tableA.e=tableB.e แบบสอบถาม 2: SELECT a,b,c,d,e FROM tableA LEFT JOIN tableB ON tableA.a=tableB.a AND tableA.b=tableB.b AND tableA.c=tableB.c AND tableA.d=tableB.d WHERE tableA.e=tableB.e ฉันถูกต้องหรือไม่ที่จะบอกว่าคำค้นหาทั้งสองนี้ให้ผลลัพธ์เหมือนกันหรือไม่ นอกจากนี้ถูกต้องหรือไม่ที่จะบอกว่าแบบสอบถามแรกสร้างตารางที่ใหญ่กว่าเพื่อทำWHEREเงื่อนไขที่ใหญ่กว่า ขณะที่กรณีที่สองเรามีตารางสร้างขนาดเล็กที่เรียบง่ายWHEREที่ใช้แล้ว สมมติว่าผลลัพธ์เหมือนกันควรเลือกแบบสอบถามใด มีปัญหาเรื่องประสิทธิภาพที่ชัดเจนหรือไม่?

4
Mysql int vs varchar เป็นคีย์หลัก (InnoDB Storage Engine?
ฉันสร้างเว็บแอปพลิเคชัน (ระบบการจัดการโครงการ) และฉันสงสัยเกี่ยวกับสิ่งนี้เมื่อพูดถึงประสิทธิภาพ ฉันมีตารางปัญหาอยู่ข้างในนั้นมี 12 ปุ่มต่างประเทศที่เชื่อมโยงกับตารางอื่น ๆ ในบรรดา 8 คนนั้นฉันต้องเข้าร่วมเพื่อรับฟิลด์ชื่อเรื่องจากตารางอื่น ๆ เพื่อให้ระเบียนมีเหตุผลในแอปพลิเคชันเว็บ 1 ฟิลด์สำหรับการรวมแต่ละรายการ ตอนนี้ฉันยังได้รับคำสั่งให้ใช้คีย์หลักที่เพิ่มขึ้นอัตโนมัติ (ยกเว้นการใช้เศษเป็นข้อกังวลในกรณีที่ฉันควรใช้ GUID) สำหรับเหตุผลด้านความคงทน แต่มันแย่ขนาดไหนในการใช้ varchar (ความยาวสูงสุด 32) ฉันหมายถึงส่วนใหญ่ของตารางเหล่านี้อาจไม่ได้มีการบันทึกจำนวนมาก (ส่วนใหญ่ควรต่ำกว่า 20) นอกจากนี้ถ้าฉันใช้ชื่อเป็นคีย์หลักฉันจะไม่ต้องรวม 95% ของเวลาดังนั้นสำหรับ 95% ของ sql ฉันจะเกิดผลการทำงานที่ยอดเยี่ยม (ฉันคิดว่า) ข้อเสียอย่างเดียวที่ฉันคิดได้ก็คือฉันมีคือฉันจะมีการใช้พื้นที่ดิสก์ที่สูงขึ้น เหตุผลที่ฉันใช้ตารางการค้นหาสำหรับสิ่งนี้มากมายแทนที่จะเป็น enums ก็เพราะฉันต้องการค่าทั้งหมดเหล่านี้เพื่อกำหนดค่าโดยผู้ใช้ผ่านแอปพลิเคชันเอง อะไรคือข้อเสียของการใช้ varchar เป็นคีย์หลักสำหรับตารางที่ไม่ได้ยกเว้นที่จะมีหลายระเบียน? อัพเดท - การทดสอบบางอย่าง ดังนั้นฉันจึงตัดสินใจทำการทดสอบเบื้องต้นเกี่ยวกับสิ่งนี้ ฉันมีบันทึก 100,000 รายการและนี่คือการสืบค้นพื้นฐาน: แบบสอบถาม VARCHAR FK …

1
ปรับปรุงประสิทธิภาพ BCP สำหรับข้อมูล BLOB
ฉันเป็นกระบวนการในการวางแผนการโยกย้ายแบบสดของฐานข้อมูล 2TB ไปยังตารางที่แบ่งพาร์ติชัน ระบบกำลังพูดอย่างกว้างขวางในการจัดเก็บเอกสารพื้นที่ส่วนใหญ่ถูกจัดสรรให้กับ LOBs ระหว่าง 50kb และ 500kb โดยมีเปอร์เซ็นต์เล็กน้อยในช่วง 500kb ถึง 1MB ส่วนหนึ่งของการโยกย้ายจะเกี่ยวข้องกับข้อมูล BCPing จากฐานข้อมูลเก่าไปยังฐานข้อมูลใหม่ BCP เป็นวิธีการที่ต้องการเนื่องจากการแบ่งปัจจุบัน / ประวัติศาสตร์ในข้อมูลอนุญาตให้แยกข้อมูลเก่าในขั้นตอน (ในช่วงเวลาที่เงียบสงบ) ล่วงหน้าของสวิตช์สุดท้ายซึ่งช่วยลดผลกระทบต่อระบบถ่ายทอดสด ปริมาณของข้อมูลและความพร้อมของการจัดเก็บติ๊ดในแหล่งกำเนิดสร้างโครงการพาร์ทิชัน ฉันสงสัยว่าอาจมีการเพิ่มประสิทธิภาพบางอย่างจากการทดลองกับ KILOBYTES_PER_BATCH มากกว่า ROWS_PER_BATCH เนื่องจากเนื้อหา BLOB แนะนำในเอกสารคู่มือBCPที่ SQL สามารถปรับการดำเนินงานให้เหมาะสมตามค่านี้ สิ่งที่ฉันไม่สามารถหาได้คือแนวทางใด ๆ เกี่ยวกับลักษณะของการเพิ่มประสิทธิภาพเหล่านี้หรือที่ที่จะเริ่มการทดสอบของฉัน ในความไม่สมบูรณ์ของคำแนะนำฉันจะลองวิ่งระยะสั้นที่ขอบเขต 4/8/16/32 / 64mb เพื่อเริ่มต้น อาจได้ประโยชน์จากการเปลี่ยนขนาดแพ็คเก็ต (พารามิเตอร์ BCP -a แทนที่จะเป็นการตั้งค่าระดับเซิร์ฟเวอร์) แต่ฉันมีแนวโน้มที่จะชนสิ่งนี้เป็นจำนวนสูงสุด 65535 เว้นแต่ว่าใครมีวิธีการสูตรมากขึ้น

4
คำสั่ง SQL Server ช้าเป็นระยะ ๆ บน SQL Server 2008 R2
ในลูกค้ารายหนึ่งของเราเราพบปัญหาเกี่ยวกับประสิทธิภาพในการสมัครของเรา เป็นแอปพลิเคชั่นเว็บ. NET 3.5 ที่ใช้งานและอัพเดทข้อมูลในฐานข้อมูล SQL Server ปัจจุบันสภาพแวดล้อมการผลิตของเราประกอบด้วยเครื่อง Windows 2008 R2 เป็นส่วนหน้าและคลัสเตอร์ SQL Server 2008 R2 ที่ส่วนหลัง แอพของเราใช้ COM + และ MSDTC เพื่อเชื่อมต่อกับฐานข้อมูล นี่คือสิ่งที่เกิดขึ้น: บางครั้งผู้ใช้ของเราบ่นว่าความเชื่องช้าในแอปพลิเคชัน บางหน้าใช้เวลาโหลดมากกว่าที่คาดไว้ ในขณะที่พยายามคิดว่าเกิดอะไรขึ้นฉันพยายามหาพฤติกรรมแปลก ๆ ในด้านฐานข้อมูลที่อาจเป็นสาเหตุให้ประสิทธิภาพการทำงานลดลง ฉันสังเกตเห็นว่าบางครั้งมีคำสั่ง SQL บางคำที่ต้องใช้เวลามากในการรันสิ่งที่คาดหวัง ฉันจัดการเพื่อระบุบางส่วนของคำสั่งเหล่านี้ (ส่วนใหญ่เป็นการเรียกร้องให้บางส่วนของขั้นตอนการจัดเก็บใบสมัครของเรา) โดยใช้การติดตาม profiler (ด้วยแม่แบบ TSQL_Duration) เพื่อระบุการสืบค้นที่ใช้เวลานาน ปัญหาคือเมื่อฉันเรียกใช้ขั้นตอนการจัดเก็บเหล่านี้โดยตรงในฐานข้อมูลใน SQL Management Studio บางครั้งพวกเขาใช้เวลานาน (ประมาณ 7/8 วินาที) บางครั้งก็รวดเร็ว (น้อยกว่า 1 …

3
ประสิทธิภาพของ SQL Server ลดลงอย่างฉับพลัน
ฉันมี SQL Server 2005 ที่คาดเดาไม่ได้ว่าล่าช้าและฉันเกาหัวว่าทำไม แบบสอบถามที่ดำเนินการในไม่กี่วินาทีกำลังเปลี่ยนแผนและใช้เวลาไม่กี่นาที (สละเวลาในการสแกนเต็มตารางหรือสปูลดัชนี) ตอนนี้สิ่งแรกและชัดเจนที่สุดคือสถิติล้าสมัยทำให้เครื่องมือเพิ่มประสิทธิภาพสับสน แต่ฉันเชื่อว่านี่ไม่ใช่กรณี - ประการแรกเนื่องจากข้อมูลพื้นฐานไม่เปลี่ยนแปลงอย่างมีนัยสำคัญ (เช่นการเพิ่มข้อมูลหนึ่งวันบนข้อมูลหนึ่งปี มีอยู่ในตารางแล้ว) และอันดับที่สองเนื่องจากสถิติการสร้างอัตโนมัติและสถิติการอัปเดตอัตโนมัติเป็นจริงทั้งคู่ แต่เพิ่มประสิทธิภาพอยู่ในการสับสน; การรัน SQL ในโปรแกรมช่วยแนะนำการปรับแต่งให้CREATE STATISTICSคำสั่งหลายคอลัมน์มากมายซึ่งดูเหมือนว่าจะแก้ไขได้ ความคิดใดของกลยุทธ์ที่ฉันสามารถใช้เพื่อเข้าใกล้รากสาเหตุนี้ ทำไมสถิติ "ปกติ" ไม่เพียงพอ?

1
วิธีแก้ไข RESOURCE_SEMAPHORE และ RESOURCE_SEMAPHORE_QUERY_COMPILE ประเภทการรอ
เรากำลังพยายามหาสาเหตุของการทำงานของ sql server ที่ทำงานช้าการสืบค้น / การดึงข้อมูลจากหนึ่งในฐานข้อมูลขนาด 300 GB โฮสต์บนเซิร์ฟเวอร์ด้วยการกำหนดค่าด้านล่าง: เซิร์ฟเวอร์ Windows 2003 R2, SP2, Enterprise Edition, RAM 16 GB, 12 CPU'S 32 บิต SQL Server 2005, SP4, Enterprise Edition, 32 บิต เราได้แจ้งธุรกิจเกี่ยวกับการอัปเกรดเป็น 64 บิตซึ่งจะใช้เวลามากกว่าหนึ่งเดือน แต่สำหรับปัญหาปัจจุบันเราพยายามรวบรวมข้อมูลถ้าเราสามารถแก้ไขความกดดันของหน่วยความจำหรือในที่สุดก็มาถึงข้อสรุปเพื่อเพิ่มแรม การดำเนินการเสร็จสิ้น: การจัดทำดัชนีและอัพเดตสถานะใหม่นั้นเหมาะสมสำหรับฐานข้อมูล ดังที่แสดงไว้ด้านล่างเราได้สังเกตสัญญาณเซมาฟอร์เป็นเวลา 5 วันที่ผ่านมาวิ่งในช่วงเวลาโหลด: ข้อมูลน้อยหลังจากแบบสอบถามด้านล่าง: ขนาดของบัฟเฟอร์ = 137272 SELECT SUM(virtual_memory_committed_kb) FROM sys.dm_os_memory_clerks WHERE type='MEMORYCLERK_SQLBUFFERPOOL' …

4
ค้นหาเพื่อนบ้านที่ใกล้ที่สุดอย่างรวดเร็วในพื้นที่ 150 มิติ
ฉันต้องการสร้างฐานข้อมูลโดยใช้ RDBMS ที่เป็นไปได้ มันจะมีตารางที่มีประมาณ 150 คอลัมน์ มีวัตถุประสงค์เพื่อทำการค้นหาเพื่อนบ้านที่ใกล้ที่สุดของวัตถุอื่น ๆ มันคือ NNS ในพื้นที่ 150 มิติ ฉันพยายามใช้วิธีที่ชัดเจนบางอย่างเช่นระยะทาง L1 หรือ L2 แต่แน่นอนว่าต้องใช้เวลานานสำหรับตารางที่มีหลายแถว ฉันพยายามลองดู KD-tree (หมายเหตุฉันไม่ได้ทดสอบ) และ PG-Strom แต่มันไม่ใช่วิธีแก้ปัญหาที่ดีสำหรับข้อมูลที่มีหลายมิติ ฉันสามารถปรับปรุงความเร็วของการค้นหาที่อธิบายโดยใช้วิธีการทางคณิตศาสตร์ (เช่น KD-tree) หรือวิธีการทางเทคโนโลยี (เช่น PG-Strom) ได้หรือไม่? ฉันจะพยายามใช้ RDBMS ใด ๆ ที่อนุญาตให้ปรับปรุงความเร็วของ NNS แต่ MySQL และ PostgreSQL นั้นเป็น DBMS ที่เหมาะสมที่สุดสำหรับฉัน

4
ทำไมคุณต้องการหลีกเลี่ยง Dynamic SQL ในขั้นตอนการจัดเก็บ?
ฉันเคยได้ยินคนหนึ่งบอกว่าคุณไม่ต้องการใช้ Dynamic SQL คุณสามารถยกตัวอย่างที่เป็นรูปธรรมหรือตัวอย่างในชีวิตจริงได้ไหม ส่วนตัวฉันรหัสมันสองสามครั้งในฐานข้อมูลของฉัน ฉันคิดว่ามันใช้ได้เพราะความยืดหยุ่น ฉันเดาว่าเกี่ยวกับ SQL Injection หรือ Performance มีอะไรอีกไหม

2
“ อัตราส่วนการเข้าแคชบัฟเฟอร์” ของ 9990 หมายถึงอะไร
ฉันได้รับข้อความค้นหานี้จากโพสต์บล็อก : SELECT object_name, counter_name, cntr_value FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%Buffer Manager%' AND [counter_name] = 'Buffer cache hit ratio' โพสต์บอกว่าจะให้เปอร์เซ็นต์ของการเข้าชมแคช ดูเหมือนว่าจะระบุว่าจะมีค่า 0-100 (แสดงให้เห็นผลลัพธ์ที่ 87) แต่เมื่อฉันเรียกใช้ฉันได้รับตัวเลขที่สูงมาก นี่คือตัวอย่าง: object_name counter_name cntr_value SQLServer:Buffer Manager Buffer cache hit ratio 9990 หมายความว่า 99.90% หรือไม่ ถ้าไม่มันหมายความว่าอย่างไร และฉันจะได้รับมูลค่าที่แท้จริงได้อย่างไร หมายเหตุ: ฉันมีค่าต่ำสุด257และสูงถึง352363 ในกรณีที่มีความเกี่ยวข้องนี่คือสถิติเซิร์ฟเวอร์อื่น ๆ บางประการ: อายุขัยของหน้า: 145 หน้าอ่าน …


2
การลดการอ่านที่ทำดัชนีด้วยเกณฑ์ที่ซับซ้อน
ฉันกำลังปรับฐานข้อมูลตั๋วทำงาน Firebird 2.5 ให้เหมาะสม พวกมันถูกเก็บไว้ในตารางที่ประกาศเช่นนี้ CREATE TABLE TICKETS ( TICKET_ID id PRIMARY KEY, JOB_ID id, ACTION_ID id, STATUS str256 DEFAULT 'Pending' ); โดยทั่วไปฉันต้องการค้นหาตั๋วใบแรกที่ยังไม่ได้ดำเนินการและอยู่ในPendingสถานะ ลูปการประมวลผลของฉันจะเป็น: รับตั๋วที่ 1 Pending ทำงานกับ Ticket อัปเดตสถานะตั๋ว => Complete ทำซ้ำ ไม่มีอะไรแฟนซีเกินไป ถ้าฉันดูฐานข้อมูลในขณะที่การวนรอบนี้ทำงานฉันจะเห็นจำนวนการอ่านดัชนีที่จัดทำขึ้นสำหรับการทำซ้ำแต่ละครั้ง ดูเหมือนว่าประสิทธิภาพจะลดลงอย่างมากไม่ได้ แต่เครื่องที่ฉันทดสอบอยู่นั้นค่อนข้างเร็ว อย่างไรก็ตามฉันได้รับรายงานประสิทธิภาพการทำงานลดลงเมื่อเวลาผ่านไปจากผู้ใช้ของฉัน ฉันได้ดัชนีมาStatusแล้ว แต่ก็ยังดูเหมือนว่ามันจะทำการสแกนTicket_Idคอลัมน์แต่ละรอบซ้ำ ดูเหมือนว่าฉันจะมองอะไรบางอย่าง แต่ฉันไม่แน่ใจ จำนวนการปีนขึ้นของการอ่านดัชนีนั้นเป็นไปตามที่คาดการณ์ไว้หรือไม่ - แก้ไขความคิดเห็น - ใน Firebird คุณจะ จำกัด …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.