ผู้ดูแลฐานข้อมูล

ถามตอบสำหรับผู้เชี่ยวชาญด้านฐานข้อมูลที่ต้องการพัฒนาทักษะฐานข้อมูลและเรียนรู้จากผู้อื่นในชุมชน

1
ข้อมูลสถิติ IO ส่งออกรวมถึงที่เก็บเวอร์ชันอ่านหรือไม่?
SQL Server มีตัวเลือกSET STATISTICS IO ONที่แสดงจำนวนหน้าตรรกะและฟิสิคัลที่อ่านสำหรับคิวรี สถิติเหล่านี้รวมถึงการอ่านที่เก็บเวอร์ชันสำหรับการสืบค้น SNAPSHOT และ RCSI หรือไม่

3
SQL Server อนุญาต (ทำให้มองเห็นได้) DDL ภายในธุรกรรมไปยังธุรกรรมก่อนที่จะส่งมอบหรือไม่?
ใน PostgreSQL ฉันสามารถสร้างตารางที่มีข้อมูลการทดสอบบางส่วนและจากนั้นในการทำธุรกรรมโยกย้ายไปยังคอลัมน์ใหม่ของรูปแบบที่แตกต่างกันส่งผลให้ในหนึ่งตารางเขียนเมื่อCOMMIT, CREATE TABLE foo ( a int ); INSERT INTO foo VALUES (1),(2),(3); ติดตามโดย, BEGIN; ALTER TABLE foo ADD COLUMN b varchar; UPDATE foo SET b = CAST(a AS varchar); ALTER TABLE foo DROP COLUMN a; COMMIT; อย่างไรก็ตามสิ่งเดียวกันใน SQL Server ของ Microsoft ดูเหมือนจะสร้างข้อผิดพลาด เปรียบเทียบซอ db db ที่ใช้งานได้โดยที่ADDคำสั่ง (คอลัมน์) …

1
เห็นได้ชัดว่าฟังก์ชั่นการประกอบ CLR ของฉันทำให้เกิดการหยุดชะงัก
แอปพลิเคชันของเราต้องทำงานอย่างเท่าเทียมกันกับฐานข้อมูล Oracle หรือฐานข้อมูล Microsoft SQL Server เพื่ออำนวยความสะดวกในเรื่องนี้เราได้สร้าง UDF จำนวนหนึ่งเพื่อทำให้ไวยากรณ์การสืบค้นของเราเป็นเนื้อเดียวกัน ตัวอย่างเช่น SQL Server มี GETDATE () และ Oracle มี SYSDATE พวกเขาทำหน้าที่เดียวกัน แต่เป็นคำที่ต่างกัน เราเขียน wrapper UDF ชื่อ NOW () สำหรับทั้งสองแพลตฟอร์มซึ่งล้อมรอบไวยากรณ์เฉพาะแพลตฟอร์มที่เกี่ยวข้องในชื่อฟังก์ชันทั่วไป เรามีฟังก์ชั่นอื่น ๆ ซึ่งบางส่วนไม่ทำอะไรเลย แต่มีอยู่เพียงเพื่อความเป็นเนื้อเดียวกัน น่าเสียดายที่ค่าใช้จ่ายนี้สำหรับ SQL Server UDF สเกลาร์แบบอินไลน์สร้างความหายนะต่อประสิทธิภาพและปิดการใช้งานความขนานอย่างสมบูรณ์ เป็นทางเลือกเราเขียนฟังก์ชันการประกอบ CLR เพื่อให้บรรลุเป้าหมายเดียวกัน เมื่อเราปรับใช้สิ่งนี้กับลูกค้าพวกเขาเริ่มประสบกับการหยุดชะงักบ่อยครั้ง ลูกค้ารายนี้ใช้การจำลองแบบและเทคนิคความพร้อมใช้งานสูงและฉันสงสัยว่ามีการโต้ตอบบางอย่างเกิดขึ้นที่นี่หรือไม่ ฉันไม่เข้าใจว่าการแนะนำฟังก์ชัน CLR จะทำให้เกิดปัญหาเช่นนี้ได้อย่างไร สำหรับการอ้างอิงฉันได้รวมข้อกำหนด UDF สเกลาร์ต้นฉบับไว้รวมถึงข้อกำหนดการแทนที่ CLR ใน …

2
ฉันจะกำจัดสาขาคู่ขนานที่ไม่มีประโยชน์ได้อย่างไรเมื่อยกเลิกการตรึงแถวเดียว
ลองพิจารณาคำถามต่อไปนี้ที่ไม่ได้รวมจำนวนสเกลาร์จำนวนไม่กี่ตัว: SELECT A, B FROM ( SELECT MAX(CASE WHEN ID = 1 THEN 1 ELSE 0 END) VAL1 , MAX(CASE WHEN ID = 2 THEN 1 ELSE 0 END) VAL2 , MAX(CASE WHEN ID = 3 THEN 1 ELSE 0 END) VAL3 , MAX(CASE WHEN ID = 4 THEN 1 …

2
ตารางที่ไม่มีคีย์หลักเป็นมาตรฐานหรือไม่
ในการบรรยายอาจารย์ของฉันแสดงให้เราเห็นตารางที่ไม่มีคีย์หลัก เมื่อถามเขาเขากล่าวว่าใน 3NF เมื่อคุณลบการอ้างอิงสกรรมกริยามันก็โอเคที่จะมีตารางที่ไม่มีคีย์หลัก อย่างไรก็ตามไม่มีคีย์หลักหมายความว่าไม่มีการพึ่งพาการทำงาน - แต่ 3NF คือการลบการพึ่งพาสกรรมกริยาและฉันได้รับการสอนว่าแต่ละตารางต้องมีคีย์หลักสำหรับการทำให้เป็นมาตรฐาน ฉันรู้ว่ามันเป็นไปได้อย่างสมบูรณ์ในการสร้างตารางโดยไม่มีคีย์หลัก แต่ฐานข้อมูลนั้นถูกพิจารณาว่าเป็นมาตรฐานหากตารางนั้นมีอยู่จริงหรือไม่ ฉันควรเพิ่มตารางไม่มี "คีย์ที่ไม่ซ้ำกัน" ไม่มีหลักไม่มีคอมโพสิตไม่มีต่างชาติ ตารางที่แสดงมีสามคุณลักษณะโดยไม่มีชื่อใดเป็นชื่อหลักหรือไม่ซ้ำกัน ฉันถามว่ามันเป็นความผิดพลาดหรือไม่และเขาบอกว่าไม่เป็นไร ฉันตั้งข้อสังเกตว่าไม่มีข้อมูลใดในตารางที่สามารถระบุได้โดยไม่ซ้ำใครและเขาอ้างว่ามันโอเคที่จะเป็นเช่นนี้ สิ่งนี้ขัดกับสิ่งที่ฉันสอนเกี่ยวกับการทำให้เป็นมาตรฐาน

3
คำหลัก“ ALIAS” ใช้จริงหรือไม่
ตาม PostgreSQL 7.1 ถึง 9.1 (ไม่สนับสนุนในขณะนี้) ALIASจะแสดงรายการเป็นคำสงวนอย่างน้อยสำหรับ SQL-99 รุ่นที่ใหม่กว่าจะไม่แสดง - แนะนำว่ามันถูกทิ้งเป็นคำสงวน เอกสาร PostgreSQL เก่ากล่าวว่า"การปรากฏตัวของคำสำคัญไม่ได้บ่งบอกถึงการมีอยู่ของคุณสมบัติ" เมื่อ aliasing ตารางหรือคอลัมน์ที่ผมเคยเห็นแต่ไม่เคยASALIAS คีย์เวิร์ด SQL ALIASใช้อยู่ที่ไหน (หรือเคย) มันเคยใช้งานหรือสงวนไว้สำหรับใช้ในอนาคตเท่านั้นหรือไม่

1
ไม่มีดัชนีที่ไม่ได้ทำคลัสเตอร์เป็นส่วนหนึ่งของดัชนีที่ทำคลัสเตอร์แล้ว
ฉันกำลังดีบักเคียวรีที่รันช้าและในแผนการดำเนินการขอแนะนำให้ใช้ดัชนีที่ไม่ใช่คลัสเตอร์โดยมีผลกระทบ 51.6648 อย่างไรก็ตามดัชนีที่ไม่ทำคลัสเตอร์จะมีเฉพาะคอลัมน์ที่อยู่ในดัชนีคอมโพสิตคีย์หลัก (PK) แล้วเท่านั้น อาจเป็นเพราะลำดับของคอลัมน์ในดัชนีหรือไม่ เช่นถ้าคอลัมน์ในดัชนีคลัสเตอร์ไม่เรียงลำดับจากส่วนใหญ่ถึงน้อยที่สุดแล้วมีความเป็นไปได้ที่จะมีดัชนีที่ไม่รวมกลุ่มเพื่อปรับปรุงประสิทธิภาพหรือไม่ นอกจากนี้ดัชนีที่ไม่ทำคลัสเตอร์จะมีคอลัมน์ PK สองในสามเท่านั้นโดยที่คอลัมน์ที่สามนั้นถูกเพิ่มเป็นคอลัมน์ที่รวมไว้ เป็นincludeอีกสาเหตุหนึ่งที่ทำไมการใช้ดัชนีที่ไม่ทำคลัสเตอร์อาจจะดีที่สุด? ด้านล่างเป็นตัวอย่างของโครงสร้างตารางที่ฉันทำงานด้วย: Tables- Retailers ( RetailerID int PK, name ...) Retailer_Relation_Types ( RelationType smallint PK, Description nvarchar(50) ...) Retailer_Relations ( RetailerID int PK FK, RelatedRetailerID int PK FK, RelationType smallint PK FK, CreatedOn datetime ...) ตารางRetailer_Relationsมีดัชนีคอมโพสิต PK ต่อไปนี้และดัชนีแนะนำ CONSTRAINT PK_Retailer_Relations …

1
ความแตกต่างระหว่างคลังข้อมูลแบบ federated และแบบกระจายอำนาจคืออะไร
ฉันไม่สามารถหาคำจำกัดความที่ชัดเจนหรือคำอธิบายใด ๆ เหล่านี้ ทั้งสองดูเหมือนกระจายอำนาจ ดูเหมือนว่าในสหพันธ์ DWH ข้อมูลจะถูกกระจายและไม่ได้รวมอยู่ในที่เก็บเดียวและเข้าถึงได้จากแหล่งที่มาแบบกระจาย ในขณะที่ในการใช้งาน DWH กระจายอำนาจข้อมูลจะถูกรวมเข้าไว้ในที่เก็บส่วนกลางหนึ่ง โปรดอธิบายความแตกต่างระหว่างการใช้งานทั้งสองนี้

1
สถิติหายไป / ว่างแบบสุ่มตลอดทั้งวัน
ฉันมีฐานข้อมูล SQL Server 2017 (CU9) ที่แสดงปัญหาที่เกี่ยวข้องกับประสิทธิภาพที่ฉันเชื่อว่าเกี่ยวข้องกับสถิติดัชนี ในขณะที่การแก้ไขปัญหาฉันพบว่าสถิติไม่ได้รับการปรับปรุง (หมายถึง DBCC SHOW_STATISTICS จะส่งกลับค่า NULL ทั้งหมด) ฉันดำเนินการอัปเดตสถิติบนตารางได้รับผลกระทบและตรวจสอบว่า SHOW_STATISTICS คืนค่าจริงเมื่อเวลา 16:00 น. เมื่อวานนี้ เช้านี้เวลา 8:00 น. สถิติว่างเปล่าอีกครั้ง (คืนค่า NULL) ไคลเอ็นต์มีงานบำรุงรักษาที่กำหนดเวลาให้รันทุกวันเวลา 4:00 น. ซึ่งทำดัชนีฐานข้อมูลอีกครั้งตามด้วยการดำเนินการของ sp_updatestats กับฐานข้อมูลทั้งหมด ฉันตรวจสอบแล้วว่าสถิติได้รับการอัปเดตเมื่อเวลา 4:00 AM ด้วยการติดตามของผู้สร้างโปรไฟล์ ฉันตกอยู่ในความสูญเสียว่าทำไมสถิติจะว่างเปล่ามันเป็นงานบำรุงรักษาที่ 4:00 AM หรือไม่? มีข้อบกพร่องที่ฉันไม่ทราบเกี่ยวกับ SQL Server รุ่นนี้หรือไม่ ขอบคุณล่วงหน้าสำหรับความช่วยเหลือของคุณ ข้อมูลเพิ่มเติม: เปิดใช้งานสถิติการอัพเดทอัตโนมัติ สถิติการอัพเดทอัตโนมัติแบบอะซิงโครนัสถูกปิดใช้งาน ปิดใช้งานการสร้างสถิติเพิ่มเติมแบบอัตโนมัติ การทำดัชนีสคริปต์ซ้ำ (Obfuscated): …

1
เมื่อคุณมี“ sql_exit_invoked” ใน System Health หมายความว่าอย่างไร
ฉันมีปัญหากับหนึ่งในเซิร์ฟเวอร์มาตรฐาน SQL Server 2016 ฉันมีเซิร์ฟเวอร์ที่ใช้งานจริง 8 แห่งและเซิร์ฟเวอร์นี้เป็นเซิร์ฟเวอร์เดียวที่ล้มเหลวแบบสุ่มโดยไม่มีการติดตามในบันทึก ฉันเปิดใช้งาน system_health อยู่ ฉันสังเกตเห็นว่าฉันมีแถวในแม่มดสุขภาพระบบคือ "sql_exit_invoked" ฉันพยายามหาข้อมูลเพิ่มเติมในแถวนั้น มันหมายความว่าอะไร? ข้อมูลเดียวที่ฉันค้นพบผ่านอินเทอร์เน็ตคือมันเกิดขึ้นเมื่อ SQLExit () ถูกเรียกใช้และมันถูกบันทึกไว้ตั้งแต่ SQL 2012 (ลิงก์มีอยู่ในเว็บไซต์ msdn ) ดังนั้นคำถามของฉันคือ: ฉันควรกังวลที่จะเห็นสิ่งนี้ในบันทึกของฉัน? ฉันพบสิ่งนี้บนเซิร์ฟเวอร์ที่มีปัญหาของฉันเท่านั้นไม่ใช่เซิร์ฟเวอร์อื่น ๆ อีก 7 เครื่อง (ทั้งหมดเป็นรุ่นมาตรฐานของ SQL Server 2016) ใครสามารถให้ข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้กับฉันได้บ้าง

1
ให้ปฏิเสธการให้สิทธิ์ซ้อน
สำหรับบทบาทdb_denycustomerฉันต้องการเฉพาะคอลัมน์รหัสของตารางลูกค้าที่สามารถเลือกได้และไม่มีรายการอื่น ๆ ดังนั้นฉันจึงทำสิ่งนี้: DENY SELECT ON dbo.customer TO db_denycustomer GRANT SELECT ON dbo.customer (code) TO db_denycustomer ... และมันก็ใช้ได้ดี เย็น! แต่ทำไม ? สิ่งที่ฉันได้อ่านในบทความที่เกี่ยวข้องคือสแต็คการอนุญาต แต่DENYมีความสำคัญกว่า ในทางตรงกันข้ามในกรณีของฉันดูเหมือนว่า "การสืบค้น" การอนุญาตครั้งล่าสุดมีความสำคัญกว่า แน่นอนถ้าฉันดำเนินการในลำดับย้อนหลังหลังDENYจะซ่อนคอลัมน์รหัสด้วย คุณช่วยอธิบายเรื่องนี้ได้ไหม ฉันได้รวมค่าเริ่มต้นdb_datawriterและdb_datareaderบทบาทให้กับผู้ใช้ที่ฉันทดสอบด้วย

1
การวัดการขับไล่แผน
เรามี SQL Server 2016 SP1 โดยมีหน่วยความจำสูงสุดตั้งไว้ที่ 24GB เซิร์ฟเวอร์นี้มีคอมไพล์จำนวนมากโดยมีเพียง 10% ของคอมไพล์เหล่านี้มาจากคิวรี Ad-Hoc ดังนั้นแผนที่รวบรวมใหม่ควรเก็บไว้ในแผนแคช แต่ขนาดของแผนแคชจะไม่เพิ่มขึ้น (ประมาณ 3.72GB) ฉันสงสัยว่ามีแรงกดดันหน่วยความจำท้องถิ่นที่นำไปสู่การลบแผนจากแคช ขีดจำกัดความดันแคชของแผนคือ 5GB (75% ของหน่วยความจำเป้าหมายที่มองเห็นได้จาก 0-4GB + 10% ของหน่วยความจำเป้าหมายที่มองเห็นได้จาก 4GB-64GB + 5% ของหน่วยความจำเป้าหมายที่มองเห็น> 64GB) เมื่อ cachestore ถึง 75% ของขีด จำกัด แรงดันควรลบแผนออกจากแคช ในกรณีของฉัน 75% จาก 5 GB คือ 3.75GB ดังนั้นจึงเป็นไปได้ที่จะเป็นสาเหตุของการคอมไพล์สูง มีวิธีวัด (perfmon, Extended events, ... ) …

3
โซลูชันสำหรับการกำหนดค่าเฉพาะให้กับแถวด้วยระยะการทำงานร่วมกันที่ จำกัด
ฉันมีตารางที่สามารถสร้างและเติมด้วยรหัสต่อไปนี้: CREATE TABLE dbo.Example(GroupKey int NOT NULL, RecordKey varchar(12) NOT NULL); ALTER TABLE dbo.Example ADD CONSTRAINT iExample PRIMARY KEY CLUSTERED(GroupKey ASC, RecordKey ASC); INSERT INTO dbo.Example(GroupKey, RecordKey) VALUES (1, 'Archimedes'), (1, 'Newton'), (1, 'Euler'), (2, 'Euler'), (2, 'Gauss'), (3, 'Gauss'), (3, 'Poincaré'), (4, 'Ramanujan'), (5, 'Neumann'), (5, 'Grothendieck'), (6, 'Grothendieck'), …

1
โอเวอร์โฟลว์ทางคณิตศาสตร์ของคิวรี SELECT
ฉันพบปัญหาทางคณิตศาสตร์มากเกินไปในคำสั่ง SELECT แบบง่าย ข้อความค้นหาดังต่อไปนี้เช่น SELECT [SaleValue] FROM Sales [SaleValue]เป็นประเภทข้อมูลdecimal(9,0)ไม่ใช่คอลัมน์ที่คำนวณ decimal(10,0)เหตุผลที่เกิดขึ้นนี้เป็นเพราะอย่างใดคอลัมน์มีแถวที่สนามนี้ได้รับการจัดเก็บค่าที่มากกว่าประเภทข้อมูลที่ระบุเช่น ฉันจะได้รับเลือกให้ทำงานเมื่อฉันเพิ่มขนาดของคอลัมน์ ตารางที่มีปัญหามีสองอินสแตนซ์อื่นในคอลัมน์และแถวอื่น ๆ ที่สอง สถานการณ์นี้เป็นไปได้อย่างไร ค่านอกช่วงถูกบันทึกไว้ในคอลัมน์ตั้งแต่แรกอย่างไร ฉันใช้เซิร์ฟเวอร์ Microsoft SQL + นี่คือตารางพื้นฐานไม่ใช่มุมมอง

2
เพิ่มกำลังรอระหว่างจุดตรวจหลังจากอัพเกรดเป็นพื้นที่เก็บข้อมูลที่ดีขึ้น
เมื่อเราย้ายจากแฟลชอาร์เรย์ทั้งหมดที่เก่ากว่าไปเป็นแฟลชอาร์เรย์ทั้งหมดที่ใหม่กว่า (ต่างกัน แต่เป็นผู้จำหน่ายที่ได้รับการยอมรับ) เราเริ่มเห็นการรอคอยเพิ่มขึ้นใน SQL Sentry ระหว่างจุดตรวจ เวอร์ชัน: SQL Server 2012 Sp4 ในที่เก็บข้อมูลเก่าของเราการรอคอยของเราอยู่ที่ประมาณ 2k ด้วย "spikes" ถึง 2,500 ในระหว่างการตรวจสอบกับที่เก็บข้อมูลใหม่ spikes มักจะ 10k กับยอดใกล้ 50k ยามชี้ให้เราเห็นว่ามีความPAGEIOLATCHสุขมากขึ้น ทำการวิเคราะห์ของเราเองดูเหมือนว่าจะเป็นการรวมกันของPAGEIOLATCH and PAGELATCHรอ การใช้ Perfmon โดยทั่วไปเราสามารถพูดได้ว่ายิ่งมีด่านมากขึ้นเท่าไรเราก็ยิ่งได้รับมากขึ้นเท่านั้น ภาระงานของเราส่วนใหญ่จะเขียน (แทรก / ปรับปรุงเป็นหลัก) ผู้จำหน่ายอุปกรณ์จัดเก็บได้พิสูจน์ให้เราเห็นแล้วว่าอาร์เรย์ที่ต่อตรงกับ Fibre Channel นั้นตอบสนองย่อย 1 ms ในระหว่างเหตุการณ์จุดตรวจสอบเหล่านี้ HBA ยังยืนยันหมายเลขของอาเรย์ด้วย เรายังไม่เชื่อว่าเป็นปัญหาการเข้าคิว HBA เนื่องจากความลึกของคิวไม่เคยสูงกว่า 8 เราได้ลองใช้ HBA …

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