मैं इसमें से एक ऑडिट योजना अपना रहा हूँ: https://weblogs.asp.net/jongalloway/adding-simple-trigger-based-auditing-to-your-sql-server-database जो इस तरह एक ऑडिट टेबल बनाने के लिए कहता है:

CREATE TABLE Audit
(
AuditID [int]IDENTITY(1,1) NOT NULL,
Type char(1), 
TableName varchar(128), 
PrimaryKeyField varchar(1000), 
PrimaryKeyValue varchar(1000), 
FieldName varchar(128), 
OldValue varchar(1000), 
NewValue varchar(1000), 
UpdateDate datetime DEFAULT (GetDate()), 
UserNamevarchar(128)
)

मैं यह सुनिश्चित करना चाहता हूं कि मैं Audit तालिका में डाली गई प्रत्येक पंक्ति के लिए जितना संभव हो उतना कम संग्रह कर रहा हूं। मेरे मामले में, मैं TableName, PrimaryKeyField, PrimaryKeyValue और FieldName की चौड़ाई को छोटा कर सकता हूं क्योंकि मुझे उन चीजों की वास्तविक अधिकतम लंबाई पता है। मेरे पास एक विशेष तालिका है जिसमें एक विशेष कॉलम है जिसे nvarchar (2000) के रूप में परिभाषित किया गया है, इसलिए यदि मैं इस सामान्य दृष्टिकोण के साथ रहता हूं तो मुझे OldValue और NewValue के लिए nvarchar (2000) का उपयोग करना होगा।

मैं वास्तव में किसी पृष्ठ में उपयोग किए जाने वाले संग्रहण स्थान के संबंध में SQL सर्वर के आंतरिक अनुकूलन के बारे में सोच रहा था। जब एक पंक्ति को लंबे वर्चर्स या nvarchars के साथ संग्रहीत किया जाता है, तो पूर्ण परिभाषित लंबाई वास्तव में किसी पृष्ठ में पंक्ति को संग्रहीत करने के लिए उपयोग की जाती है, या SQL सर्वर केवल उपयोग किए गए वास्तविक बाइट्स को संग्रहीत करता है। उदाहरण के लिए, यदि उपरोक्त OldValue में केवल Hello! संग्रहीत है, तो OldValue वास्तव में ऐसी पंक्ति के लिए पृष्ठ में कितने बाइट्स होंगे?

1
Brian Eriksen 9 अप्रैल 2017, 16:35

2 जवाब

सबसे बढ़िया उत्तर

के लिए nvarchar(N) यह 2 + (2*N) इस मान के लिए पंक्ति में संग्रहीत अधिकतम बाइट्स होगा। पहले 2 लंबाई हैं, और फिर 2 बाइट्स प्रति यूनिकोड वर्ण वास्तव में पंक्ति में संग्रहीत हैं। यह कब्जा की गई अधिकतम जगह है।

यदि आपका यूनिकोड स्ट्रिंग केवल 15 वर्णों का है तो यह 32 बाइट्स (यहां तक ​​कि एक nvarchar(2000) डेटाटाइप के रूप में) होगा।

मैं आपकी स्क्रिप्ट में आगे (और पिछड़े) संगतता के लिए सिस्टम ऑब्जेक्ट के नामों के लिए sysname का उपयोग करने की भी सिफारिश करूंगा।

आपको इस ऑडिट स्क्रिप्ट में भी दिलचस्पी हो सकती है: त्वरित और आसान ऑडिट टेबल्स - डेव ब्रिटन

0
SqlZim 9 अप्रैल 2017, 16:45

जब एक पंक्ति लंबे वर्चर्स या nvarchars के साथ संग्रहीत की जाती है, तो पूर्ण परिभाषित लंबाई वास्तव में किसी पृष्ठ में पंक्ति को संग्रहीत करने के लिए उपयोग की जाती है, या SQL सर्वर केवल उपयोग किए गए वास्तविक बाइट्स को संग्रहीत करता है

भले ही, आप एक चर लंबाई कॉलम को परिभाषित करते हैं, SQL केवल घोषित किए गए मानों के लिए संग्रहण स्थान का उपयोग करेगा।

इसे यहां कवर किया गया है: SQL सर्वर डेटाबेस में varchar मान कैसे संग्रहीत किए जाते हैं?

मार्टिन स्मिथ के उत्तर से लिया गया प्रासंगिक हिस्सा नीचे दिया गया है:

सभी वर्चर डेटा पंक्ति के अंत में एक चर लंबाई खंड में संग्रहीत किया जाता है (या यदि यह पंक्ति में फिट नहीं हो सकता है तो ऑफ्रो पृष्ठों में)। उस खंड में खपत की जाने वाली जगह की मात्रा (और यह पंक्ति से समाप्त होती है या नहीं) पूरी तरह से वास्तविक डेटा की लंबाई पर निर्भर करती है न कि कॉलम घोषणा

इसे साबित करने के लिए नीचे एक नमूना डेमो है

create table dbo.test1

(
fixedlencol varchar(400),
varlengthcol varchar(max),
var_len_Nvarcahrcol nvarchar(max)
)

insert into dbo.test1
values
('a','abc','def')

अब अगर यहां से उदाहरण के बाद DBCC पेज और DBCC IND का उपयोग करें: स्टोरेज इंजन के अंदर: डीबीसीसी पेज और डीबीसीसी आईएनडी का उपयोग करके पता करें कि क्या पेज स्प्लिट कभी वापस रोल करता है< /ए>

नीचे आउटपुट है, मुझे पहली पंक्ति डालने के लिए मिला है

स्लॉट 0 कॉलम 1 ऑफसेट 0xf लंबाई 1 लंबाई (भौतिक) 1

फिक्स्डलेनकोल = ए

varlengthcol = [BLOB इनलाइन डेटा] स्लॉट 0 कॉलम 2 ऑफ़सेट 0x10 लंबाई 3 लंबाई (भौतिक) 3

varlengthcol = 0x616263

var_len_Nvarcahrcol = [बीएलओबी इनलाइन डेटा] स्लॉट 0 कॉलम 3 ऑफसेट 0x13 लंबाई 6 लंबाई (भौतिक) 6

अंतिम कॉलम वास्तविक लंबाई से डबल बाइट लेने का कारण नवरचर के कारण है।

0
Community 20 जून 2020, 12:12