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

เรามีตาราง 2.2 GB ใน Postgres ที่มี 7,801,611 แถว เรากำลังเพิ่มคอลัมน์ uuid / guid ลงไปและฉันสงสัยว่าวิธีที่ดีที่สุดในการเติมข้อมูลคอลัมน์นั้นคืออะไร (ตามที่เราต้องการเพิ่มNOT NULLข้อ จำกัด ) หากฉันเข้าใจ Postgres อย่างถูกต้องการอัปเดตเป็นเทคนิคลบและแทรกดังนั้นนี่คือการสร้างตาราง 2.2 gb ใหม่ทั้งหมด นอกจากนี้เรายังมีทาสวิ่งอยู่ดังนั้นเราจึงไม่ต้องการให้มันล้าหลัง มีวิธีใดที่ดีไปกว่าการเขียนสคริปต์ที่ค่อยๆเติมมันลงไปตามกาลเวลา?

33 postgresql  storage  ddl 

ฉันพยายามที่จะสร้างฐานข้อมูลโดยใช้สองดิบคือพาร์ทิชันที่ยังไม่ฟอร์แมต Microsoft เอกสารระบุว่าคุณสามารถทำได้คุณเพียงแค่ระบุตัวอักษรไดรฟ์ของพาร์ทิชันดิบเช่นเดียวกับใน: CREATE DATABASE DirectDevice ON (NAME = DirectDevice_system, FILENAME = 'S:') LOG ON (NAME = DirectDevice_log, FILENAME = 'T:') อย่างไรก็ตาม SQL Server 2017 ส่งคืนข้อผิดพลาดนี้: ข่าวสารเกี่ยวกับ 5170 ระดับ 16 สถานะ 4 บรรทัด 1 ไม่สามารถสร้างไฟล์ 'S:' ได้เนื่องจากมีอยู่แล้ว เปลี่ยนพา ธ ของไฟล์หรือชื่อไฟล์แล้วลองดำเนินการอีกครั้ง เกี่ยวกับข้อความ 1802 ระดับ 16 สถานะ 4 บรรทัดที่ 1 สร้างฐานข้อมูลล้มเหลว ไม่สามารถสร้างชื่อไฟล์บางรายการ …

16 sql-server  storage 

ในการผลิต SQL Server เรามีการกำหนดค่าดังต่อไปนี้: 3 เซิร์ฟเวอร์ Dell PowerEdge R630 ซึ่งรวมอยู่ในกลุ่มความพร้อมใช้งานทั้งหมด 3 เชื่อมต่อกับหน่วยเก็บข้อมูล Dell SAN เดียวซึ่งเป็นอาร์เรย์ RAID ในบางครั้งในระดับประถมศึกษาเราเห็นข้อความคล้ายกับด้านล่าง: SQL Server พบคำขอ I / O 11 รายการที่เกิดขึ้นในเวลานานกว่า 15 วินาทีเพื่อให้เสร็จสมบูรณ์ในไฟล์ [F: \ Data \ MyDatabase.mdf] ใน id ฐานข้อมูล 8 การจัดการไฟล์ OS คือ 0x0000000000001FBC ออฟเซ็ตของ I / O ที่ยาวล่าสุดคือ: 0x000004295d0000 ระยะเวลาของ I / O …

16 performance  performance-tuning  sql-server-2017  storage 

ฉันมีตารางในฐานข้อมูลการผลิตที่มีขนาด 525 GB ซึ่งไม่ได้ใช้ 383 GB: ฉันต้องการเรียกคืนพื้นที่บางส่วนนี้ แต่ก่อนที่จะยุ่งกับฐานข้อมูลการผลิตฉันกำลังทดสอบกลยุทธ์บางอย่างในตารางที่เหมือนกันในฐานข้อมูลทดสอบที่มีข้อมูลน้อยลง ตารางนี้มีปัญหาที่คล้ายกัน: ข้อมูลบางอย่างเกี่ยวกับตาราง: ปัจจัยเติมถูกตั้งค่าเป็น 0 มีประมาณ 30 คอลัมน์ หนึ่งในคอลัมน์คือ LOB ของรูปภาพประเภทและมันจัดเก็บไฟล์ที่มีขนาดตั้งแต่ไม่กี่ KB ถึงหลายร้อย MB ตารางนี้ไม่มีดัชนีสมมุติฐานที่เกี่ยวข้อง เซิร์ฟเวอร์กำลังเรียกใช้ SQL Server 2017 (RTM-GDR) (KB4505224) - 14.0.2027.2 (X64) ฐานข้อมูลใช้SIMPLEโมเดลการกู้คืน บางสิ่งที่ฉันได้ลอง: ALTER INDEX ALL ON dbo.MyTable REBUILDสร้างใหม่ดัชนี: สิ่งนี้มีผลกระทบเล็กน้อย ALTER INDEX ALL ON dbo.MyTable REORGANIZE WITH(LOB_COMPACTION = ON)จัดระเบียบดัชนี: สิ่งนี้มีผลกระทบเล็กน้อย …

15 sql-server  index  sql-server-2017  storage 

ในเอกสาร PostgreSQL มีการกล่าวกันว่าชนิดข้อมูลจำนวนเต็มสามารถเก็บไว้ในพื้นที่สอง, สี่หรือแปดไบต์ หนึ่งในคอลัมน์ของตารางในฐานข้อมูลของฉันมีค่าจำนวนเต็มหนึ่งไบต์และฉันต้องการเก็บไว้ในประเภทข้อมูลหนึ่งไบต์ มีส่วนขยายหรือวิธีใช้ชนิดข้อมูลจำนวนเต็มหนึ่งไบต์ใน PostgreSQL หรือไม่ NUMERIC (1,0) มีกี่ไบต์

14 datatypes  storage  postgresql-9.6 

ฉันมีตารางที่อัปเดตบ่อยมากที่มี 240 ล้านแถว (และเพิ่มขึ้น) ทุกๆสามชั่วโมง 1.5 ล้านแถวจะถูกแทรกและ 1.5 ล้านแถวจะถูกลบ เมื่อฉันย้ายคลัสเตอร์ไปยัง SSD เวลาแทรกจำนวนมาก (โดยใช้การคัดลอก) นี้ถูกตัดจาก 22 นาทีเป็น 2.3 นาที เวลาลบก็ดีขึ้นเช่นกัน ฉันวางแผนที่จะทำการอัปเดตจำนวนมากนี้ทุกสองชั่วโมงหรือทุกชั่วโมง แม้ว่าประสิทธิภาพในตอนนี้ (หลังจาก SSD) เข้ากันได้กับการอัปเดตบ่อยครั้งมากขึ้นฉันได้อ่านเรื่องราวสยองขวัญเกี่ยวกับการตายของ SSD เนื่องจากความอดทนของ NAND จำกัด รวมกับการขยายการเขียน เนื่องจาก SSD มีราคาแพงฉันจึงต้องการผลักดันความตายไปสู่อนาคตเท่าที่จะทำได้ ดังนั้นคำถามของฉัน: เกิดอะไรขึ้นกับไฟล์ดิสก์ในการลบและสูญญากาศที่ตามมา? ฉันเดาว่ามีการเขียนดิสก์สองรายการหนึ่งรายการเพื่อทำเครื่องหมายแถวว่าถูกลบและอีกรายการหนึ่งเมื่อดูดฝุ่นเพื่อทำเครื่องหมายว่าพร้อมใช้งานเพื่อเขียนทับ หากแทนที่การลบและการดูดฉันจะแบ่งพาร์ติชันตารางที่สร้างและวางตารางที่แต่ละส่วนแทรก / ลบจำนวนมากฉันจะลดการสึกหรอของ SSD หรือไม่

13 postgresql  partitioning  delete  storage  vacuum 

Senior DBA ก่อนหน้านี้ตั้งค่าจุดเชื่อมต่อสำหรับไดรฟ์ทั้งหมดของเราทั่วทุกเซิร์ฟเวอร์ SQL ทั่วทั้ง บริษัท Senior DBA ใหม่นั้นน่ากลัวมากเพราะคะแนนของเขาต้องการเปลี่ยนมาตรฐานของเรา (ส่วนใหญ่ฉันคิดว่าเพราะเขาไม่มีประสบการณ์กับพวกเขา) จากผลลัพธ์ของการค้นหาทางอินเทอร์เน็ตจำนวนมากฉันไม่พบเหตุผลใด ๆ (post-SQL Server 2000) ที่ไม่ใช้จุดเชื่อมต่อ มีใครทราบถึงข้อ จำกัด ของระบบปฏิบัติการ Windows ที่เกี่ยวข้องกับหัวข้อนี้หรือไม่? ฉันเคยได้ยินคำกล่าวอ้างว่า "ระบบปฏิบัติการไม่รู้จักจุดเชื่อมต่อ" มากเมื่อเร็ว ๆ นี้ (ไม่จริงขึ้นอยู่กับการวิจัยของฉันเป็นรุ่นของ Windows Server ที่เราใช้) มีเหตุผลหรือหลักฐานจากประสบการณ์ที่จะไม่ใช้จุดเชื่อมต่อกับ SQL Server หรือไม่? สมมติว่าตัวอักษรไดรฟ์หมดไม่มีปัญหาสำหรับเรา ฉันเข้าใจว่าจุดยึดนั้นมีประโยชน์อย่างมากสำหรับการแยกเวิร์กโหลด ทุกคนสามารถยืนยันหรือปฏิเสธความเข้าใจของฉันว่าจุดเชื่อมต่อนั้นแยก / แยกปริมาณงานของข้อมูลและไฟล์บันทึกประเภทต่างๆ (ไฟล์ฐานข้อมูลระบบไฟล์ฐานข้อมูลผู้ใช้ tempDB) มีประสิทธิภาพมากกว่าไดรฟ์หนึ่งตัวสำหรับไฟล์ข้อมูลล็อกไฟล์และ tempdb ?

12 sql-server  storage  architecture  mount-point 

ลองนึกภาพความต้องการของคุณคือคุณมีตารางขนาดใหญ่ 3 ตาราง (ข้อมูลที่มีโครงสร้าง) โดยมีจำนวนแถวละ 30,000 ล้านแถว (ขนาดรวม 4TB) และผู้ใช้ที่ใช้งานพร้อมกันจำนวนมาก (ซึ่งเป็นเธรดระบบปฏิบัติการแบบขนานบนเครื่อง LAN ระยะไกล) ข้อมูลผ่าน SELELCT WHERE GROUPBY ของพวกเขาและพร้อมกันสูงพูด 10,000 อ่านพร้อมกันในเวลาเดียวกันและผู้ใช้จำเป็นต้องแทรกข้อมูล (ไม่มีการปรับปรุง) ลงในตารางเหล่านี้พร้อมกันสูงเช่นนักเขียนพร้อมกัน 2000 (ทั่วเครือข่าย LAN ของศูนย์ข้อมูล) . ผู้ใช้ต้องการอ่านและแทรกให้เร็วที่สุดเท่าที่จะเป็นไปได้ในรูปแบบที่เก็บข้อมูลนี้ซึ่งการอ่านและเขียนแต่ละอันจะเกิดขึ้นคือ ms ถึง 1 วินาที เทคโนโลยีใดที่คุณแนะนำให้ตอบสนองความต้องการดังกล่าว มีที่เก็บข้อมูลหรือที่เก็บค่าคีย์ที่สามารถทำสิ่งนี้ได้หรือไม่? คลาวด์ไม่ใช่ตัวเลือก ชี้แจงบางส่วน: ผู้ใช้ไม่จำเป็นต้องเห็นข้อมูลทันทีและยอมรับความสอดคล้องในที่สุด ข้อมูลสามารถเข้าถึงได้ผ่านทุกไดรเวอร์ที่หน่วยเก็บข้อมูลสามารถให้และผู้ใช้จะเป็นเพียงเธรดที่ทำงานบนเครื่องระยะไกลของศูนย์ข้อมูล ข้อความค้นหาส่วนใหญ่จะเป็นเหมือน SELECT WHERE GROUPBY ข้อมูลอยู่ในรูปแบบตารางและแต่ละแถวมีขนาดประมาณ 60 ไบต์ ไม่มีตัวเลือกคลาวด์ที่ฉันไม่สามารถใช้ DynamoDB หรือโซลูชันที่คล้ายกัน ฉันต้องสามารถโฮสต์ภายในศูนย์ข้อมูลได้ ข้อมูลทั้งหมดของตารางสามารถอ่านได้ตลอดเวลาและรูปแบบการใช้งานไม่แน่นอน …

12 architecture  concurrency  nosql  storage 

ฉันพยายามเข้าใจวิธีที่ดีที่สุดในการตัดสินใจว่าคอลัมน์ varchar ขนาดใหญ่ควรเป็นอย่างไรทั้งจากมุมมองการจัดเก็บและประสิทธิภาพ ประสิทธิภาพ จากการวิจัยของฉันดูเหมือนว่าควรใช้ varchar (สูงสุด) เฉพาะในกรณีที่คุณต้องการเท่านั้น นั่นคือถ้าคอลัมน์จะต้องรองรับมากกว่า 8000 ตัวอักษรเหตุผลหนึ่งคือการขาดการจัดทำดัชนี (แม้ว่าฉันน่าสงสัยเล็กน้อยของการจัดทำดัชนีในเขตข้อมูล varchar โดยทั่วไปฉันค่อนข้างใหม่กับหลักการ DB แม้ว่าอาจจะไม่มีมูลเลย ) และการบีบอัด (ยิ่งกังวลเรื่องพื้นที่เก็บข้อมูล) ในความเป็นจริงแล้วคนทั่วไปดูเหมือนจะแนะนำให้ใช้เฉพาะสิ่งที่คุณต้องการเมื่อทำ varchar (n) .... การ oversize ไม่ดีเพราะการสืบค้นจะต้องคำนึงถึงขนาดสูงสุด แต่ก็มีการระบุด้วยว่าเครื่องยนต์จะใช้ขนาดครึ่งหนึ่งที่ระบุไว้เป็นค่าประมาณขนาดเฉลี่ยจริงของข้อมูล นี่หมายความว่าเราควรกำหนดจากข้อมูลว่าขนาดเฉลี่ยคืออะไรเพิ่มขนาดเป็นสองเท่าและใช้เป็น n สำหรับข้อมูลที่มีค่าความแปรปรวนต่ำมาก แต่ไม่เป็นศูนย์ นี่หมายถึงการขยายขนาดเกินขนาดสูงสุด 2 เท่าซึ่งดูเหมือนจะมาก แต่อาจไม่ใช่หรือ ข้อมูลเชิงลึกจะได้รับการชื่นชม ที่เก็บข้อมูล หลังจากอ่านเกี่ยวกับวิธีการทำงานของหน่วยเก็บข้อมูลแบบ in-row และ out-of-row และโปรดทราบว่าการจัดเก็บข้อมูลจริงนั้น จำกัด อยู่ที่ข้อมูลจริงฉันคิดว่าตัวเลือกของ n นั้นมีพื้นที่เก็บข้อมูลน้อยมากหรือไม่มีเลย ทำให้แน่ใจว่ามันใหญ่พอที่จะเก็บทุกอย่างไว้ได้) แม้แต่การใช้ varchar (สูงสุด) …

12 sql-server  performance  best-practices  storage  varchar 

เรากำลังเรียกใช้ Linux VM จำนวนมากในสภาพแวดล้อมการจัดเก็บข้อมูลแบบ vmware / ที่ใช้ร่วมกันซึ่งแต่ละตัวใช้งานอินสแตนซ์ของตนเองของ postgreSQL (รวม 9.0 และ 9.3) ปัจจุบัน VM ทั้งหมดตั้งอยู่บนพาร์ติชัน / ไดรฟ์หนึ่งรูทและเราประสบความสำเร็จอย่างมาก (~ 8 ปี) โดยใช้สแนปชอตจากสตอเรจของโวลุ่ม VMFS พื้นฐานสำหรับกระบวนการสำรองข้อมูล / คืนค่า (และทำซ้ำไปยังไซต์ DR ของเรา) เนื่องจากสถาปัตยกรรมของที่เก็บข้อมูลของเรามันจะเป็นประโยชน์ในการแยก postgres ไฟล์ WAL ออกเป็นปริมาณที่ไม่แคชส่วนใหญ่เขียนเพื่อให้เราปั่นแคชน้อยลงในด้านการจัดเก็บ ด้วยที่จัดเก็บข้อมูลของเรา (Nimble Storage) เราสามารถกำหนดทั้งสองวอลุ่มให้กับกลุ่มการป้องกัน / สแน็ปช็อตเดียว แต่ฉันไม่สามารถล้วงข้อมูลจากผู้ขายของเราได้ว่าสแน็ปช็อตจะเกิดขึ้นในเวลาเดียวกันในทุกวอลุ่มในกลุ่มการป้องกัน - มีแนวโน้มที่จะเป็นไปได้ แต่มีโอกาสเสมอที่มิลลิวินาทีแยกกัน ด้วยเหตุนี้เราจึงทำการทดลองบางอย่างขณะที่เขียนข้อมูลไปยังฐานข้อมูลให้เร็วที่สุดโดยใช้ pg_bench หลังจากการทดลองเรากู้คืนไดรฟ์ข้อมูล snapshot ของเราและเริ่ม VM + …

11 postgresql  storage  virtualisation 

เมื่อเราย้ายจากแฟลชอาร์เรย์ทั้งหมดที่เก่ากว่าไปเป็นแฟลชอาร์เรย์ทั้งหมดที่ใหม่กว่า (ต่างกัน แต่เป็นผู้จำหน่ายที่ได้รับการยอมรับ) เราเริ่มเห็นการรอคอยเพิ่มขึ้นใน 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 …

9 sql-server  sql-server-2012  storage  waits  checkpoint 

ฉันรู้ว่านี่อาจเป็นคำถามสิ้นสุดที่เปิดกว้างและคำตอบอาจแตกต่างกันไป แต่ตำแหน่งที่เหมาะสมที่สุดสำหรับไฟล์ tempdb, mdf และ ldf ใน SQL Server 2012 เมื่อพูดถึง SSD คืออะไร การซื้อล่วงหน้าใหม่ฉันมี SSD ที่มีอยู่ซึ่งมีไฟล์หลักของ SQL Server 2012 และ tempdb ติดตั้งอยู่และมีทั้ง mdf / ldf บน HDD 7200 รอบต่อนาที จากนั้นฉันก็ซื้อ SSD 2 ตัวโดยมีเจตนาดั้งเดิมที่จะวาง mdf ลงบนหนึ่ง ldf และใส่อีกอันหนึ่ง แต่จากการอ่านเพิ่มเติมดิสก์แยกทางกายภาพสำหรับไฟล์ mdf และ ldf ไม่ได้นำมาใช้จริง ๆ กับ SSD แก้ไข? ดังนั้นฉันคิดต่อไปนี้: SSD 1 - …

9 sql-server  sql-server-2012  storage 

ฉันมีตารางบันทึกทั่วไปแถวประมาณ 5 เมตร มีฟิลด์ "พิมพ์อย่างยิ่ง" ที่จัดเก็บประเภทเหตุการณ์และมีคอลัมน์ "พิมพ์จำนวนมาก" ที่ประกอบด้วยข้อมูลที่เกี่ยวข้องกับเหตุการณ์ นั่นคือความหมายของคอลัมน์ "ที่พิมพ์แบบแพ้ ๆ " นั้นขึ้นอยู่กับประเภทของเหตุการณ์ คอลัมน์เหล่านี้ถูกกำหนดเป็น: USER_CHAR1 nvarchar(150) null, USER_CHAR2 nvarchar(150) null, USER_CHAR3 nvarchar(150) null, USER_CHAR4 nvarchar(150) null, USER_CHAR5 nvarchar(150) null, USER_INTEGER1 int null, USER_INTEGER2 int null, USER_INTEGER3 int null, USER_INTEGER4 int null, USER_INTEGER5 int null, USER_FLAG1 bit null, USER_FLAG2 bit null, …

9 sql-server  sql-server-2008  null  storage  sparse-column