SQL Server xp_delete_file لا يحذف الملفات

Question

أحاول كتابة بعض SQL التي ستحذف الملفات من النوع ".7z" التي مضى عليها أكثر من 7 أيام.

إليك ما لدي والذي لا يعمل:

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

لقد حاولت أيضًا تغيير "1" في النهاية إلى "0".

يؤدي هذا إلى إرجاع "النجاح"، ولكن لا يتم حذف الملفات.

أنا أستخدم SQL Server 2005، Standard، w/SP2

Answer 1

وكان مشكلة مماثلة، وجدت إجابات مختلفة. وهنا ما وجدت.

وأنت لا تستطيع حذف ملفات 7Z مع xp_delete_file. هذا هو إجراء غير شرعي بمد المخزن الذي هو المستمر من SQL 2000. ويتحقق السطر الأول من الملف المراد حذفه للتحقق من أنه إما أن يكون ملف النسخ الاحتياطي SQL أو ملف تقرير SQL. لا يتحقق على أساس ملف التمديد. من ما جمع استخدام المقصود منها في خطط الصيانة لالنسخ الاحتياطي القديمة تنظيف والتقارير الخطة.

وفيما يلي عينة بناء على وصلة Tomalak لحذف ملفات النسخ الاحتياطي التي يزيد عمرها عن 7 أيام. ما رحلات الناس حتى هو مخطط "تميز الكلية، مائل زائدة في مسار المجلد، وليس نقطة في ملحق الملف الذي تبحث عنه. المستخدم الذي يدير SQL Server كما أيضا يحتاج إلى أذونات الحذف على المجلد.

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 في SP2 ولن تعمل على ملفات التقرير؛ هناك إصلاح عاجل لذلك في [ http://support.microsoft.com/kb/938085]. أنا لم نجرب ذلك مع SP3.

وبما أنها لا يحملون وثائق، xp_delete_file قد تذهب بعيدا أو تغيير في الإصدارات المستقبلية من SQL Server. العديد من المواقع يوصي شيل للقيام الحذف بدلا من ذلك.

Answer 2

وAFAIK xp_delete_file حذف الملفات فقط المعترف بها بواسطة SQL Server 2005 (ملفات النسخ الاحتياطي، وسجلات المعاملات، ...). ربما يمكنك أن تجرب شيئا من هذا القبيل:

xp_cmdshell 'del <filename>'

Answer 3

وهذه ليرة سورية سوف فقط سوف تحذف فقط مزود خدمة الأصلي ملفات النسخ الاحتياطي أو ملفات تقرير صيانة الأصلي (لأغراض أمنية)

وكما اقترح Smink يمكنك استخدام

xp_cmdshell 'del <filename>'

مع الأذونات المناسبة على المجلد.

Answer 4

ولقد وجدت هذا السؤال، ولكن لم الحل لا تنطبق على لي (كما كان الملفات باك، قد SQL Server نفسه قامت، كجزء من خطة الصيانة).

وكانت القضية في حالتي الأمن. ويجري تشغيل البرنامج النصي باسم المستخدم الذي يبدأ SQL خادم (MSSQL) (في حالتي، وربما معظم الحالات "خدمة الشبكة") لم يكن لديك الوصول إلى المجلد انها تحاول حذف الملفات في.

وهكذا مضيفا "خدمة الشبكة" ومنحها "تعديل" ساعد.

Answer 5

لقد قرأت العديد من الأساليب والحلول المختلفة التي اتبعها العديد من الأفراد عند محاولة حل المشكلة باستخدام الإجراء المخزن الموسع xp_delete.الحلول هي:

1. تأكد من عدم وجود نقطة (.) في الامتداد عند تكوين مهمة صيانة SSIS.
2. تأكد من النقر فوق المجلدات الفرعية تضمين المستوى الأول إذا كانت موجودة لكل نسخة احتياطية لقاعدة البيانات.
3. تأكد من النقر على ملفات النسخ الاحتياطي في الأعلى.تقوم مهمة الصيانة بالتحقق من نوع الملف.بالنسبة للنسخ الاحتياطية لقاعدة البيانات، أعتقد أنه يتحقق من رأس ملف النسخ الاحتياطي.

في السيناريو الخاص بي، كل ما سبق كان صحيحا.هناك عدد قليل من التعليقات على الويب حيث قال البعض إن نظام xp_delete الروتيني به أخطاء.

عندما لم يتم حذف ملفات النسخ الاحتياطي، قمت باستخراج SQL للصيانة وتشغيله من SSMS.كانت الرسالة الناتجة هي أن الملف ليس ملف نسخة احتياطية لخادم SQL.كانت هذه الرسالة خاطئة لأنه من الممكن استعادة النسخة الاحتياطية بنجاح، مما أدى إلى إنشاء قاعدة بيانات تشغيلية.

أوامر قاعدة البيانات المستخدمة للتحقق من قاعدة البيانات هي:

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

أشار كلا الأمرين أعلاه إلى أن ملف النسخة الاحتياطية كان صالحًا.

بعد ذلك، فتحت عارض الأحداث وعثرت على رسائل تشير إلى وجود أخطاء في تسجيل الدخول لمدير الاتصال.كان هذا غريبًا لأنني قمت بالتحقق من صحة الاتصال باستخدام زر اختبار الاتصال.لم تكن الأخطاء مرتبطة بأي حساب قمت بإنشائه.

رسالة عارض الأحداث:

*لا يمكن العثور على وصف معرف الحدث 17052 من المصدر MS SQL SERVER.إما أن المكون الذي يثير هذا الحدث غير مثبت على الكمبيوتر المحلي الخاص بك أو أن التثبيت تالف.يمكنك تثبيت أو إصلاح المكون على الكمبيوتر المحلي.إذا نشأ الحدث على كمبيوتر آخر، فيجب حفظ معلومات العرض مع الحدث.

تم تضمين المعلومات التالية مع الحدث:

خطورة:16 خطأ: 18456، نظام التشغيل:18456 [Microsoft] [SQL Server Native Client 11.0] [SQL Server] فشل تسجيل الدخول للمستخدم 'domain\servername$'.*

بعد ذلك قمت بتسجيل الدخول إلى جهاز حيث كان xp_delete يعمل بشكل صحيح.بعد مراجعة الدليل النشط وعدم العثور على حساب النظام، انتقلت إلى عارض الأحداث للعثور على رسائل مماثلة.أصبح من الواضح هنا أن حساب domain\server$ قد تم تعيينه لأمان النظام.

كانت الخطوة التالية هي مقارنة أمان قاعدة البيانات حيث يعمل xp_delete مع قاعدة البيانات التي لم يعمل فيها.كانت هناك عمليتا تسجيل دخول مفقودتان تحت الأمان في قاعدة البيانات حيث لم يعمل xp_delete.عمليتا تسجيل الدخول المفقودتان هما:NT Authority System NT Service mssqlserver

بعد إضافة خدمة NT\MSSQLSERVER، عمل xp_delete بنجاح.

أحد أساليب الاختبار هو استخدام مهمة الصيانة لحذف ملف فردي.

Answer 6

وحاول تغيير المعلمة الأولى 0-1.

وهنا هو على xp_delete_file أنا فقط وجدت. يبدو قليلا مثل كنت يكون من الحظ مع هذا الإجراء.

Answer 7

وأعرف أن هذا هو العمر قليلا ولكن أردت أن حصة الإحباطات بلدي معكم جميعا. كنت أعاني من نفس المشكلة والكثير من هذه الوظائف ولكن لا شيء يبدو على العمل. وبعد ذلك تذكرت أن لدينا طبقة التشفير على قاعدة بيانات تسمى NetLib. وهذا يعني أن النسخ الاحتياطي مشفرة وعلى هذا النحو، xp_delete_file لا يمكن قراءة رؤوس. أنا الآن استخدام ملف دفعي في نظام التشغيل والذي يطلق عليه من وظيفة وكيل. آمل أن يساعد هذا شخص.

Answer 8

ونحن عادة ما تنتهي في مثل هذه الحالات عندما يكون لديك نقل قاعدة البيانات إلى ملقم آخر أو عند إعادة تثبيت مثيل SQL على نفس واحد ولكن تبقى النسخ الاحتياطي في الدليل القديم. فمثلا: قمت بنقل قاعدة البيانات من SERVER1 إلى SERVER2، ولكن لديك ملقم مع خطة الصيانة التي يقوم نسخة احتياطية الدوري أو إعادة تثبيت مثيل SQL على Server1 و استعادة قاعدة البيانات.

في حالة النسخ الاحتياطي مجموعات التي يتم الاحتفاظ بها قدر من المعلومات في البيانات msdb لم تعد هناك، لذلك جميع النسخ الاحتياطي القديمة التي تم إنشاؤها لن يتم حذف كما لا توجد معلومات يتم التحقق من فشل المستمدة من الجداول مع مجموعات النسخ الاحتياطي.

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

والوسيطة الأولى تبين أن الجداول من البيانات msdb يتم استخدامها.

وآمل أن يساعد هذا شخص.