2008-10-17 11 views
12

मैं कुछ एसक्यूएल लिखने की कोशिश कर रहा हूं जो 7 दिनों से पुराने पुराने '.7z' की फ़ाइलों को हटा देगा।SQL सर्वर xp_delete_file फ़ाइलों को हटा नहीं रहा

DECLARE @DateString CHAR(8) 
SET @DateString = CONVERT(CHAR(8), DATEADD(d, -7, GETDATE()), 1) 
EXECUTE master.dbo.xp_delete_file 0, 
        N'e:\Database Backups',N'7z', @DateString, 1 

मैं भी एक '0' के लिए '1' एक अंत को बदलने की कोशिश की है:

यहाँ मैं क्या मिल गया है कि काम नहीं कर रहा है।

यह 'सफलता' देता है, लेकिन फाइलें हटाई नहीं जा रही हैं।

मैं SQL सर्वर 2005 का उपयोग कर रहा, स्टैंडर्ड, डब्ल्यू/SP2

उत्तर

19

एक ही समस्या थी, विभिन्न उत्तरों पाए गए। मुझे जो मिला वह यहां है।

आप xp_delete_file के साथ 7z फ़ाइलों को हटा नहीं सकते हैं। यह एक अनियंत्रित विस्तारित संग्रहीत प्रक्रिया है जो SQL 2000 से होल्डओवर है। यह सत्यापित करने के लिए फ़ाइल की पहली पंक्ति को हटाया जाता है कि यह या तो SQL बैकअप फ़ाइल या SQL रिपोर्ट फ़ाइल है। यह फ़ाइल एक्सटेंशन के आधार पर जांच नहीं करता है। जो मैं अपने इच्छित उपयोग को इकट्ठा करता हूं उससे पुराने बैकअप और योजना रिपोर्ट को साफ करने के लिए रखरखाव योजनाओं में है।

यहां 7 दिनों से अधिक पुरानी बैकअप फ़ाइलों को हटाने के लिए टॉमलाक के लिंक पर आधारित एक नमूना है। लोग क्या यात्रा करते हैं 'sys' स्कीमा, फ़ोल्डर पथ में पिछला स्लैश, और फ़ाइल एक्सटेंशन में कोई बिंदु देखने के लिए नहीं है। उपयोगकर्ता जो SQL सर्वर चलाता है उसे फ़ोल्डर पर अनुमतियों को हटाने की भी आवश्यकता होती है।

DECLARE @DeleteDate datetime 
SET @DeleteDate = DateAdd(day, -7, GetDate()) 

EXECUTE master.sys.xp_delete_file 
0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport) 
N'D:\SQLbackups\', -- folder path (trailing slash) 
N'bak', -- file extension which needs to be deleted (no dot) 
@DeleteDate, -- date prior which to delete 
1 -- subfolder flag (1 = include files in first subfolder level, 0 = not) 

ध्यान दें कि xp_delete_file एसपी 2 में टूटा हुआ है और रिपोर्ट फाइलों पर काम नहीं करेगा; इसके लिए [http://support.microsoft.com/kb/938085] पर एक हॉटफिक्स है। मैंने एसपी 3 के साथ इसका परीक्षण नहीं किया है।

चूंकि यह अनियंत्रित है, इसलिए xp_delete_file दूर जा सकता है या SQL सर्वर के भविष्य के संस्करणों में बदल सकता है। कई साइटें इसके बजाय हटाए जाने के लिए शेल स्क्रिप्ट की अनुशंसा करती हैं।

0

को 1.

0 से पहले पैरामीटर बदलने का प्रयास करें यहां एक छोटा summary on xp_delete_file मैं सिर्फ पाया जाता है। थोड़ा सा लगता है जैसे आप इस प्रक्रिया के साथ भाग्य से बाहर होंगे।

+0

तोमालक: यह काम नहीं किया। – GernBlandston

+0

मुझे लगा, सारांश पढ़ने के बाद मैंने अभी पोस्ट किया था। एक गुमराह मंच पोस्ट कहीं मेरे पहले जवाब की दिशा में इंगित किया। – Tomalak

6

AFAIK xp_delete_file केवल SQL सर्वर 2005 (बैकअप फ़ाइलें, लेनदेन लॉग, ...) द्वारा मान्यता प्राप्त फ़ाइलों को हटाएं। शायद आप कुछ इस तरह की कोशिश कर सकते हैं:

xp_cmdshell 'del <filename>'
+0

धुआं: मैंने भाग्य के बिना फ़ाइल एक्सटेंशन को .bak में बदलने का प्रयास किया है। क्या यह फ़ाइल को देखने के लिए देखता है कि क्या मैं एक्सटेंशन को देखने के बजाय इसके साथ गड़बड़ कर रहा हूं? – GernBlandston

+0

हां यह फ़ाइल के बाइनरी हस्ताक्षर की जांच करता है। –

+0

मैंने एक .bak sql बैकअप फ़ाइल के साथ प्रयास किया और इसे हटा नहीं दिया। – GernBlandston

3

यह एसपी केवल के रूप में Smink सुझाव केवल देशी एसक्यूएल सर्वर बैकअप फ़ाइलों या देशी रखरखाव रिपोर्ट फ़ाइलें (सुरक्षा उद्देश्यों के लिए)

को नष्ट करेगा आप उपयोग कर सकते हैं

xp_cmdshell 'del <filename>' 

फ़ोल्डर पर उचित अनुमतियों के साथ।

1

मुझे यह प्रश्न मिला, लेकिन समाधान मेरे लिए लागू नहीं हुआ (जैसा कि यह था। बीक फाइलें, एसक्यूएल सर्वर ने रखरखाव योजना के हिस्से के रूप में स्वयं बनाया था)।

मेरे मामले में समस्या सुरक्षा थी। स्क्रिप्ट को उपयोगकर्ता के रूप में चलाया जा रहा था जो SQL सर्वर (MSSQL) शुरू करता है (मेरे मामले में और शायद अधिकांश मामलों "नेटवर्क सेवा") में उस फ़ोल्डर तक पहुंच नहीं थी जिसमें वह फ़ाइलों को हटाने की कोशिश कर रहा था।

तो "नेटवर्क सेवा" जोड़ना और इसे "संशोधित" करने में सहायता मिली।

0

मुझे पता है कि यह थोड़ा पुराना है लेकिन मैं आप सभी के साथ अपनी निराशा साझा करना चाहता था। मुझे इन पदों में से बहुत सी समस्याएं थीं लेकिन कुछ भी काम नहीं कर रहा था। तब मुझे याद आया कि हमारे पास NetLib नामक डेटाबेस पर एक एन्क्रिप्शन परत है। इसका मतलब है कि बैकअप एन्क्रिप्ट किए गए हैं और इस तरह, xp_delete_file शीर्षलेख नहीं पढ़ सकता है। अब मैं ओएस में बैच फ़ाइल का उपयोग करता हूं और उसे एजेंट जॉब से कॉल करता हूं। उम्मीद है कि यह किसी की मदद करता है।

0

हम आमतौर पर ऐसी स्थितियों में समाप्त होते हैं जब आपके पास डेटाबेस किसी अन्य सर्वर पर स्थानांतरित होता है या जब एक SQL इंस्टेंस को उसी पर पुनर्स्थापित किया जाता है लेकिन बैकअप पुरानी निर्देशिका में छोड़ा जाता है। उदाहरण के लिए: आप डेटाबेस को सर्वर 1 से सर्वर 2 पर ले जाते हैं, लेकिन आपके पास एक रखरखाव योजना वाला सर्वर है जो आवधिक बैकअप करता है या आप सर्वर 1 और पर SQL इंस्टेंस को पुनर्स्थापित करते हैं, तो आप डेटाबेस को पुनर्स्थापित करते हैं।

बैकअप मामले में एमएसडीबी में जानकारी के रूप में रखे गए सेट अब नहीं हैं, इसलिए बनाए गए सभी पुराने बैकअप को हटाया नहीं जाएगा क्योंकि बैकअप सेट के साथ तालिकाओं से व्युत्पन्न विफलताओं से चेक किया गया है ।

EXECUTE master.sys.xp_delete_file 0, -- FileTypeSelected (0 = FileBackup, 1 = FileReport) 

पहला तर्क दिखाता है कि एमएसडीबी से टेबल का उपयोग किया जा रहा है।

उम्मीद है कि यह किसी की मदद करेगा।

0

मैंने विस्तारित संग्रहीत प्रक्रिया xp_delete के साथ समस्या को हल करने का प्रयास करते समय कई अलग-अलग दृष्टिकोण और समाधान कई व्यक्तियों को पढ़ा था। समाधान हैं:

  1. एसएसआईएस रखरखाव कार्य को कॉन्फ़िगर करते समय एक्सटेंशन में अवधि (।) नहीं रखना सुनिश्चित करें।
  2. यदि वे प्रत्येक डेटाबेस बैकअप के लिए मौजूद हैं तो प्रथम श्रेणी के उप फ़ोल्डरों को शामिल करना सुनिश्चित करें।
  3. शीर्ष पर बैकअप फ़ाइलों पर क्लिक करना सुनिश्चित करें। रखरखाव कार्य फ़ाइल प्रकार की जांच करता है। डेटाबेस बैकअप के लिए, मेरा मानना ​​है कि यह बैकअप फ़ाइल शीर्षलेख की जांच करता है।

मेरे परिदृश्य में, उपर्युक्त सभी सही थे। वेब पर कुछ टिप्पणियां हैं जहां कुछ ने कहा कि नियमित xp_delete छोटी है।

जब बैकअप फ़ाइलों को हटाया नहीं जा रहा था, तो मैंने रखरखाव के लिए एसक्यूएल निकाला और इसे एसएसएमएस से चलाया। परिणामस्वरूप संदेश था कि फ़ाइल एक SQL सर्वर बैकअप फ़ाइल नहीं थी। यह संदेश गलत था क्योंकि बैकअप को सफलतापूर्वक बहाल किया जा सकता था, जिसके परिणामस्वरूप एक परिचालन डेटाबेस होता था।

डेटाबेस डेटाबेस सत्यापित करने के लिए इस्तेमाल किया आदेशों थे:

RESTORE HEADERONLY FROM DISK = N'<file path\filename>.Bak' 
RESTORE VERIFYONLY FROM DISK = N'<file path\filename>.bak' 

ऊपर बताए गए आदेशों के दोनों संकेत दिया बैकअप फ़ाइल वैध था।

अगला मैंने ईवेंट व्यूअर खोला और संदेश मिला कि कनेक्शन प्रबंधक के लिए लॉगिन त्रुटियां थीं। यह अजीब था क्योंकि मैंने परीक्षण कनेक्शन बटन के साथ कनेक्शन को सत्यापित किया था। त्रुटियां मेरे द्वारा बनाए गए किसी भी खाते से संबंधित नहीं थीं।

ईवेंट व्यूअर संदेश:

*The description for Event ID 17052 from source MS SQL SERVER cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event.

निम्न जानकारी घटना के साथ शामिल किया गया था:

Severity: 16 Error:18456, OS: 18456 [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user 'domain\servername$'.*

अगला मैं एक मशीन जहां xp_delete सही ढंग से कार्य कर रहा था में प्रवेश किया। सक्रिय निर्देशिका की समीक्षा करने और सिस्टम खाता नहीं ढूंढने के बाद, मैं इवेंट व्यूअर को इसी तरह के संदेशों को ढूंढने के लिए आगे बढ़ गया। यहां यह स्पष्ट हो गया है कि डोमेन \ सर्वर $ के लिए खाता सिस्टम सुरक्षा के लिए मैप किया गया है।

अगला चरण डेटाबेस सुरक्षा की तुलना करना था जहां xp_delete डेटाबेस के विरुद्ध काम करता था जहां यह काम नहीं करता था। डेटाबेस में सुरक्षा के तहत 2 गायब लॉग इन थे जहां xp_delete काम नहीं करता था। 2 लापता लॉगिन थे: NT AUTHORITY \ SYSTEM NT सेवा \ MSSQLSERVER

NT सेवा \ MSSQLSERVER जोड़ने के बाद, xp_delete सफलतापूर्वक काम किया।

परीक्षण के लिए एक दृष्टिकोण एक व्यक्तिगत फ़ाइल को हटाने के लिए रखरखाव कार्य का उपयोग करना है।

संबंधित मुद्दे