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

6
เหตุใดจึงใช้ทั้ง TRUNCATE และ DROP
ในระบบฉันทำงานมีจำนวนมากของขั้นตอนการจัดเก็บและสคริปต์ SQL ที่ใช้ประโยชน์จากตารางชั่วคราว หลังจากใช้ตารางเหล่านี้แล้วก็เป็นการดีที่จะวาง เพื่อนร่วมงานของฉันหลายคน (เกือบทุกคนมีประสบการณ์มากกว่าฉัน) โดยทั่วไปแล้วทำสิ่งนี้: TRUNCATE TABLE #mytemp DROP TABLE #mytemp ฉันมักจะใช้ซิงเกิ้ลDROP TABLEในสคริปท์ของฉัน มีเหตุผลที่ดีในการทำTRUNCATEทันทีก่อนDROP?

3
ตัดทอนตาราง 200GB แต่พื้นที่ดิสก์ไม่ออก
ฉันเหลือเพียง 2GB ดังนั้นฉันต้องลบตารางประวัตินี้ ตารางนี้ในขณะนี้ว่างเปล่า แต่พื้นที่ดิสก์ฐานข้อมูลไม่ออก และไฟล์ฐานข้อมูล 320GB

2
เหตุใด DELETE จึงมีผลกระทบต่อประสิทธิภาพอย่างมาก
ในตอนท้ายคือสคริปต์ทดสอบสำหรับเปรียบเทียบประสิทธิภาพระหว่างตัวแปร @table และตาราง #temp ฉันคิดว่าฉันตั้งค่าไว้อย่างถูกต้อง - การกำหนดเวลาการทำงานนั้นเกิดขึ้นนอกคำสั่ง DELETE / TRUNCATE ผลลัพธ์ที่ฉันได้รับมีดังนี้ (คูณเป็นมิลลิวินาที) @Table Variable #Temp (delete) #Temp (truncate) --------------- -------------- ---------------- 5723 5180 5506 15636 14746 7800 14506 14300 5583 14030 15460 5386 16706 16186 5360 เพียงเพื่อให้แน่ใจว่าฉันมีสติสิ่งนี้แสดงให้เห็นว่า CURRENT_TIMESTAMP (aka GetDate()) ถูกนำมาใช้ในเวลาของคำสั่งไม่ใช่ของแบตช์ดังนั้นจึงไม่มีการโต้ตอบระหว่าง TRUNCATE / DELETE กับSET @StartTime = CURRENT_TIMESTAMPคำสั่ง select current_timestamp …


2
เหตุใดจึงตัด DDL
ฉันมีคำถามสัมภาษณ์ซึ่งถูกถามระหว่างการสัมภาษณ์ ฉันตอบคำถาม แต่ผู้สัมภาษณ์ไม่เชื่อมั่นกับคำตอบของฉัน ดังนั้นทุกคนโปรดแก้ไขฉันด้วยความเข้าใจของฉัน Q. ทำไม Truncate เป็น DDL ที่ไหนในขณะที่ Delete เป็น DML ทั้งสองทำงานเกือบเหมือนกัน (ลบแถว) Ans เมื่อเราใช้ Truncate เราจะยกเลิกการจัดสรรพื้นที่ทั้งหมดที่จัดสรรโดยข้อมูลโดยไม่บันทึกลงใน undo-table-space แต่ในกรณีของการลบเราจะใส่ข้อมูลทั้งหมดในเลิกทำพื้นที่ตารางแล้วเราจะลบข้อมูลทั้งหมด กรุณาถ้าใครรู้คำตอบที่ดีที่สุดสำหรับข้างต้นโปรดอธิบาย
15 oracle  delete  ddl  truncate 

1
เหตุใดจึงตัดทอนตาราง temp ที่ส่วนท้ายของโพรซีเดอร์ที่เก็บไว้ซึ่งสร้างพื้นที่ว่าง tempdb ให้เร็วขึ้น?
SQL Server แคชตาราง temp ที่สร้างขึ้นภายในโพรซีเดอร์ที่เก็บไว้และเปลี่ยนชื่อเพียงเมื่อโพรซีเดอร์สิ้นสุดลงและถูกเรียกใช้งานในภายหลัง คำถามของฉันเกี่ยวกับเมื่อมีการปล่อยพื้นที่ tempdb ผมเคยอ่านว่าตารางจะถูกตัดทอนในตอนท้ายของขั้นตอนที่ ฉันได้อ่านความคิดเห็นว่าสิ่งนี้ได้รับการจัดการในแต่ละช่วงและเห็นคำถามว่าจำเป็นต้องตอบคำถามเกี่ยวกับการล้างข้อมูลบน MSDNหรือไม่ แต่ถ้าหากมันไม่ถูกดำเนินการโดยเซสชั่นเดียวกันสองครั้ง? ฉันเคยได้ยินว่ามีกระบวนการเก็บรวบรวมขยะในพื้นหลังที่ทำให้มีพื้นที่ว่างเมื่อตารางไม่อยู่ในขอบเขต การตัดทอนตาราง temp ที่ส่วนท้ายของโพรซีเดอร์ที่เก็บไว้ซึ่งทำให้ดูเหมือนว่าพื้นที่ที่ตารางใช้ใน tempdb สำหรับข้อมูลที่จะเผยแพร่เร็วกว่าถ้าไม่มีการใช้คำสั่ง truncate แม้จะมีความคาดหวังที่ตรงกันข้าม ทำไม? อะไรคือความสัมพันธ์ของประสิทธิภาพในการใช้งานหรือไม่ใช้คำสั่งตัดทอน เมื่อใช้การแยก SNAPSHOT, tempdb มักจะเครียดและฉันคิดว่าการปล่อยพื้นที่ที่ใช้ใน tempdb จากตาราง tempdb ขนาดใหญ่โดยเร็วที่สุดจะช่วยป้องกันไม่ให้ tempdb เติบโตอย่างไม่จำเป็น การประหยัดพื้นที่ที่มีศักยภาพนี้จะมาพร้อมกับประสิทธิภาพหรือไม่ นี่คือรหัสบางส่วนในการทำซ้ำปัญหา (ส่วนใหญ่มาจาก @TheGameiswar โดยมีการเปลี่ยนแปลงบางอย่าง): SET NOCOUNT ON; GO ALTER PROC usp_test AS BEGIN IF object_id('tempdb..#temp') IS NOT NULL …

1
PostgreSQL: พื้นที่ว่างในดิสก์ไม่ได้ถูกปล่อยออกหลังจาก TRUNCATE
ฉันมีTRUNCATEตารางขนาดใหญ่ (~ 120Gb) ที่เรียกว่าfiles: TRUNCATE files; VACUUM FULL files; ขนาดตารางคือ 0 แต่ไม่มีพื้นที่ดิสก์ออก แนวคิดใดบ้างที่จะเรียกคืนพื้นที่ดิสก์ที่หายไป ปรับปรุง: พื้นที่ว่างในดิสก์ได้รับการปล่อยตัวหลังจาก ~ 12 ชั่วโมงโดยไม่มีการดำเนินการใด ๆ ในด้านของฉัน ฉันใช้เซิร์ฟเวอร์ Ubuntu 8.04

1
ธุรกรรมแยกระดับ SNAPSHOT กับ TRUNCATE?
ฉันหวังว่าจะมีใครบางคนแสดงความเข้าใจบางอย่างเกี่ยวกับพฤติกรรมนี้ซึ่งฉันไม่ได้คาดหวังเกี่ยวกับการแยก SNAPSHOT กับ TRUNCATE ฐานข้อมูล: อนุญาตการแยก Snapshot = True; Is Snapshot On Read ที่ได้รับการยอมรับ = False ขั้นตอนที่ 1 (แทนที่เนื้อหาของ table foo จาก SELECT ที่ซับซ้อนที่รันเป็นเวลานานด้วยการรวมจำนวนมาก): BEGIN TRAN; TRUNCATE TABLE foo; INSERT INTO foo SELECT...; COMMIT; ขั้นตอนที่ 2 (อ่านจากตาราง foo): SET TRANSACTION ISOLATION LEVEL SNAPSHOT; SELECT * FROM foo; หากโพรซีเดอร์ 1 กำลังรันในขณะที่โพรซีเดอร์ …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.