এটির প্রাথমিক আকারের নীচে একটি ডাটাবেস সঙ্কুচিত করুন

10

আমি একটি এসকিউএল সার্ভার 2005 ডেভ ডাটাবেস পেয়েছি যা একটি লাইভের 30 জিবি অনুলিপি। আমরা এমন কিছু ডেটা মুছে ফেলেছি যা দেবের প্রয়োজন হয় না, যা ডেটা ফাইলের স্পেসকে 20 জিবিতে নামিয়ে আনে। সুতরাং আমরা প্রায় 33% অব্যবহৃত আছে।

আমাকে স্থানটি পুনরায় দাবি করতে হবে, যা আমাদের সার্ভারে একটি দ্বিতীয় ডিবি ডিবি করার অনুমতি দেবে (কাটা ডাউন সংস্করণের ভিত্তিতে); তবে আমি স্থানটি পুনরায় দাবি করতে পারি না, আমি নিম্নলিখিতটি করেছি:

ফাইলটির প্রাথমিক আকার SMS2_Data30GB।
```
DBCC SHRINKFILE (N'SMS2_Data' , 0, TRUNCATEONLY)
```
অনুসরণ করেছে
```
DBCC SHRINKFILE (N'SMS2_Data' , 19500)
```

আনন্দ নেই। আমি ব্যাকআপ তৈরির চেষ্টা করেছি, একটি কম প্রাথমিক আকার নিয়ে একটি নতুন ডিবি তৈরি করে আবার পুনরুদ্ধার করছি, প্রাথমিক আকারটি ওভাররাইট হয়ে যাওয়ার কারণে কোনও আনন্দ নেই। চেষ্টাও করেছেন:

ALTER DATABASE SMS2HazSub MODIFY FILE (NAME = 'SMS2_Data', SIZE = 20000)

এই ভুল করে বলেছেন:

মোডিফাই ফাইলটি ব্যর্থ হয়েছে। নির্দিষ্ট আকার বর্তমান আকারের চেয়ে কম।

আমি 20800 চেষ্টা করেছি এবং তারপরে 29000 (29GB) অবধি চলতে থাকি এবং এটি এখনও আমাকে এটি পরিবর্তন করতে দেয় না।

সঙ্কুচিত হয়ে গেলে পুনরুদ্ধার মোডটি আবার FULLথেকে SIMPLEএবং পিছনে ফিরে যায়। আনন্দ নেই।

আমি ভেবেছিলাম এটি কিছু TEXTক্ষেত্রের সাথে করা উচিত। সিস্টেম জুড়ে আমাদের প্রায় 6 টি রয়েছে। সুতরাং একটি পরীক্ষা হিসাবে আমি সেগুলি সব ফেলে দিয়েছিলাম এবং তারপরে ফাইলটি সঙ্কুচিত করেছিলাম এবং এখনও কোনও পরিবর্তন আছি না।

আর একমাত্র বিকল্পটি বাক্যটি অন্য ডিবিতে ডেটা রিম্পোর্ট করা। এটি ব্যবহারিক নয়, কারণ এটি লাইভ ডিবিতে করা উচিত, যা খুব বেশি ঝুঁকি বহন করে। আমরা নিয়মিতভাবে লাইভ ডিবি-এর একটি অনুলিপি দখল করি এবং দেব / পরীক্ষাকে ওভাররাইট করি। আমাদের কাছে 500 টেবিলের মতো কিছু রয়েছে। আমি এটি করার এমন একটি উপায় চাই যাতে কোনও নতুন ডিবিতে ডেটা রফতানির ঝুঁকি থাকে না।

আমি ডেটা অন্য ফাইলে স্থানান্তরিত করার চেষ্টা করেছি এবং এটি 5% ডেটা ব্যতীত সমস্ত অনুলিপি করেছে। এটিই আমাকে সমস্ত পাঠ্য কলামগুলি চেষ্টা করে ফেলতে চেষ্টা করে।

সার্ভারটি উপযুক্ততা মোড 90 এ রয়েছে তবে এসপি 2। আমি এখন নিম্নলিখিত 3 বার করেছি: সমস্ত টেবিল, ব্যাকআপ ডাটাবেস, ফাইল সঙ্কুচিত, ডাটাবেস সঙ্কুচিত। তবুও আনন্দ নেই।

EXECUTE sp_spaceused আয়:

database_name   database_size   unallocated space
SMS2Tests       31453.94 MB     13903.16 MB

reserved     data         index_size   unused
16545568 KB  10602264 KB  4254360 KB   1688944 KB

sql-server sql-server-2005 shrink

— পল হোয়াইট 9
সূত্র

3

কিছু লোক ইতিমধ্যে উল্লিখিত হিসাবে আপনি নতুন ডাটাবেস তৈরি করতে এবং পুরানো ডাটাবেস থেকে "অনুলিপি" স্টাফ তৈরি করতে পারে। এটি আপনার জন্য সেরা বিকল্প হবে। তবে আমি লক্ষ্য করেছি যে আপনি এটি নিয়মিত করতে চান। সুতরাং আপনার সেরা বিকল্পটি হ'ল রেডগেট ডেটা তুলনা এবং রেডগেটের তুলনা । উভয়ই রেডগেট স্কেলটিউলবেল্ট প্যাকেজের অংশ ।

তো তুমি কি করো:

ছোট ছোট আকারের একটি খালি ডিবি তৈরি করুন।
পুরানো ডিবি থেকে ডিবি কাঠামো, ফাংশন ইত্যাদি অনুলিপি করতে রেডগেট ব্যবহার করুন
রেডগেট ডেটা ব্যবহার করুন পুরাতন ডাটাবেস থেকে নতুন একটিতে অনুলিপি করতে ডেটা তুলনা করুন
আপনি ডেভ ডাটাবেসে কাজ করেন এবং তারপরে যে কোনও সময় আপনি কেবল ডেটা তুলনা এবং নিয়মিত ডেভ ডিবি আপডেট করেন বা আপনি যদি ডিবিতে কোনও পরিবর্তন করেন আপনি রেডগেট তুলনা ব্যবহার করে এবং রেডগেট ডেটা তুলনা করে সেই পরিবর্তনগুলি মোতায়েন করতে পারেন।

ডেটা তুলনার সাথে যা ভাল তা হ'ল আপনি সেই 30 জিবি ডেটা অনুলিপি করার পরে (আপনি এটি কেবল কিছু টেবিল দিয়ে শুরু করে করতে পারেন) কিছুক্ষণ পরে কেবলমাত্র কিছু পরিবর্তন 'পুনরায় তুলনা' করতে হবে এবং পুরো 30gb ডেটা নয়। যার অর্থ এটি উভয় ডাটাবেসে অনেক কম প্রভাব ফেলবে তবে এটি অনুলিপি করে অনুলিপি করবে।

— MadBoy
সূত্র

2

এখানে কয়েকটি সম্ভাবনা।

প্রথমত, আপনি এসকিউএল 2005 এসপি 3 বা তার পরে? কিছু পূর্ববর্তী সংস্করণগুলিতে SHRINKFILE সমস্যাগুলি রিপোর্ট করেছেন (দেখুন http://www.sqlservercentral.com/forums/Topic981292-146-6.aspx#bm985164 )

দ্বিতীয়ত, আপনি যাচাই করতে পারবেন যে ডেটাবেসটি মোড 90 সাথে সামঞ্জস্যযোগ্য, এবং মোড 80 নয়? এটি স্পষ্টতই এসকিউএল 2000 এর একটি সমস্যা ছিল তবে এসকিউএল 2005 সালে এই বিধিনিষেধটি প্রত্যাহার করা হয়েছে your

তৃতীয়ত, এটি LOB ডেটা (পাঠ্য, নেক্সট, বার্চার (সর্বোচ্চ)) এর সাথে সমস্যা হতে পারে। পল র্যান্ডাল এর দুর্দান্ত নিবন্ধটি এখানে দেখুন

আমি ধরে নিচ্ছি যে SHRINKing আসলে কী করে আপনি তা বুঝতে পেরেছেন এবং এটি আপনার কার্যক্ষমতাতে নেতিবাচক প্রভাব ফেলতে পারে:

SHRINK ফাইলের শেষে থেকে শুরু পর্যন্ত অন্ধভাবে পৃষ্ঠা সরিয়ে কাজ করে
যেমনটি, এটি মারাত্মকভাবে সূচকগুলি টুকরো টুকরো টুকরো টুকরো টানতে পারে, যা উল্লেখযোগ্য পারফরম্যান্স সমস্যার কারণ হতে পারে
কারণ এর যেমন একটি ডেটা নিবিড় অপারেশন, সঙ্কুচিত হওয়াতে উল্লেখযোগ্য সময় নিতে পারে

আমি সাধারণত একটি পূর্ণ পুনর্নির্দেশের সাথে সংকুচিত হওয়ার অনুসরণ করার পরামর্শ দিই (যা কেবলমাত্র মুক্ত হওয়া স্থানটির কিছু দাবি করবে), তবে আপনি এমনকি এই মুহুর্তে পৌঁছাতে সক্ষম হবেন বলে মনে হচ্ছে না।

আপনি যদি ক্রিয়াকলাপের মনিটরে আপনার সঙ্কুচিত এসপিআইডিটি দেখেন, এটি কি কিছু করছে বলে মনে হচ্ছে? (আইও এবং সিপিইউ কাউন্টার পরিবর্তন হচ্ছে) বা এটি অবরুদ্ধ করা হয়েছে? কেবলমাত্র অন্য যে জিনিসটি আমি ভাবতে পারি তা হ'ল যদি ডাটাবেসে অন্য ক্রিয়াকলাপ থাকে, সঙ্কুচিত হওয়া অবরুদ্ধ করে। অন্য কোনও সক্রিয় স্পিডস সেই সময় ডাটাবেসটি ব্যবহার করছে না তা নিশ্চিত করুন।

এই প্রক্রিয়া চলাকালীন সরল পুনরুদ্ধারের মোডে স্যুইচ করাও একটি ভাল ধারণা, লগটি খুব বেশি বাড়তে না পারে।

— BradC
সূত্র

1

আপনি যদি সত্যিই এটি করতে চান:

সহজ মোড পুনরুদ্ধার সেট
সতর্ক হোন: DBCC SHRINKDATABASE (MyDatabase, TRUNCATEONLY);

— p.campbell
সূত্র

1

SHRINKDATABASE ডাটাবেসটি কেবলমাত্র তার মিনিসাইজে সঙ্কুচিত করবে (যাতে সর্বোত্তমভাবে) এটি আপনাকে সাহায্য করবে না।

আপনি যখন ডিফল্টগুলি ব্যবহার করে এসএসএমএস ইউআইয়ের মাধ্যমে ফাইলটি সঙ্কুচিত করার চেষ্টা করেন, তখন এটি 'ডিবিসিসি শ্রিনকিফাইল (এন'মাইডিবি', ০, সত্যবাদী) 'ব্যবহার করে। এই কমান্ডটি কেবলমাত্র শেষ বরাদ্দকৃত পরিমাণে ফাইলটি (সর্বোত্তমভাবে) সঙ্কুচিত করবে।

আপনি যদি মিনিসাইজের নীচে ফাইলটি সঙ্কুচিত করতে চান তবে কেবল এমবিতে ফাইল সঙ্কুচিত করার চেষ্টা করতে চান এমন প্যারামিটারটি DBCC SHRINKFILE0 থেকে আকারে পরিবর্তন করুন । একটি শূন্য নয় নম্বর SHRINKFILE কে সম্ভব হলে ফাইলটিকে সেই আকারে সঙ্কুচিত করতে বলবে। সুতরাং DBCC SHRINKFILE('MyDB', 300, TRUNCATEONLY)ডাটাবেসের স্থান হয়েছে থাকে 300MB ফাইল সঙ্কুচিত হবে।

আপনি এটি চালিয়ে মিনিসাইজটি দেখতে পারেন:

DBCC TRACEON(3604)
go
DBCC PAGE('MyDB', 1, 0, 3) with tableresults
go

এমবিগুলিতে মিনিসাইজটি এইভাবে গণনা করা হয়: (মিনিসাইজ * 8) / 1024

— infoone
সূত্র

0

আপনার কাছে যদি বলুন, ডাটাবেসে প্রকৃত ডাট্যাট 20003 (এমবি) থাকে তবে "SIZE = 20000" খুব ছোট হবে। 21000 বা 25000 দিয়ে চেষ্টা করুন, দেখুন কি এটি কাজ করে। (এবং মনে রাখবেন, 1 জিবি = 1024 এমবি।)

— ফিলিপ কেলি
সূত্র

0

চেষ্টা

DBCC SHRINKDATABASE (N'SMS2_Data' , 0)

আমি এখানে এসকিউএল 2005 ডাটাবেসে এটি ব্যবহার করেছি এবং ডেটা ফাইলের জন্য বরাদ্দ করা স্থানটি 10.2 জিবি থেকে 3 জিবিতে গিয়েছিল।

ফাই, এটি একটি দীর্ঘ প্রক্রিয়া, এবং আমার ডেটাবেসের জন্য 19 মিনিটের বেশি সময় নিয়েছিল।

পিএস সবেমাত্র চেক করা হয়েছে এবং আমার ডাটাবেসের জন্য রিকভারি মডেলটি সহজতে সেট করা হয়েছে।

এটি কোনও পার্থক্য করেনি, আমি নিশ্চিত যে সামনের দিকে শেষ হয়ে যায় same

0

আমি ধরে নিচ্ছি যে আপনার যৌক্তিক নাম SMS2_Data সহ একটি একক ডাটাবেস ফাইল রয়েছে। ডাটাবেসে আপনার এক বা একাধিক লেনদেন লগ ফাইল রয়েছে।

আপনার কাছে একটি চ্যালেঞ্জ রয়েছে যা ডাটাবেসের বর্তমান অনুলিপিটিতে ঠিক করা যায় না। আপনি যে তথ্যটি জানিয়েছেন সেটির গুরুত্বপূর্ণ অংশটি হ'ল 'ডাটাবেস ফাইলটির মূল আকার 30 গিগাবাইট'। দুর্ভাগ্যক্রমে, এই ফাইলটি তার মূল আকারের চেয়ে ছোট সঙ্কুচিত করা যাবে না।

আপনি ইতিমধ্যে অভিজ্ঞ হিসাবে, SHRINKDB এবং SHRINKFILE আপনাকে যা চান তা আপনাকে দিচ্ছে না। এই কমান্ডগুলি মুল আকারের নিয়মের চেয়ে ছোট সঙ্কোচ করতে পারে না follow সুতরাং, আপনি কেবলমাত্র মূল ডাটাবেসে একটি ডাটাবেস সঙ্কুচিত করতে পারেন এবং এর চেয়ে ছোটও নয়।

ডাটাবেস ব্যাকআপ এবং একটি বিদ্যমান, ছোট ডাটাবেস পুনরুদ্ধার কাজ করে না। আপনি যখন একটি ডাটাবেস পুনরুদ্ধার করবেন, ডাটাবেস ফাইলগুলি ফাইলের আকারে পুনরুদ্ধার করা হ'ল ব্যাকআপের সময়। এবং, পুনরুদ্ধার মডেলটির (সাধারণ, পূর্ণ, ইত্যাদি) এই সমস্যার সাথে কোনও প্রাসঙ্গিকতা নেই।

এবং, একটি শেষ খারাপ খবর পয়েন্ট। আপনি ডাটাবেসে অন্যান্য, ছোট ডাটাবেস ফাইলগুলি যুক্ত করার কথা বিবেচনা করতে পারেন, 30 জিবি ফাইলের মধ্যে থেকে সমস্ত ডেটা স্থানান্তর করতে পারেন এবং তারপরে এটি ফেলে দিন। দুর্ভাগ্যক্রমে, এটি কাজ করবে না কারণ আপনি ডাটাবেস থেকে প্রাথমিক ফাইলটি মুছতে পারবেন না।

সুতরাং, সর্বোত্তম সমাধান হ'ল ডেটাটি অন্য ডাটাবেসে অনুলিপি করা। আপনার এখানে কয়েকটি বিকল্প রয়েছে এবং সম্ভবত আপনি সেগুলি সম্পর্কে ইতিমধ্যে অবগত আছেন। প্রথম পদক্ষেপটি এমন একটি নতুন ডেটাবেস তৈরি করা হয় যা ডেটা আকারের চেয়ে ছোট size তারপরে, আপনি প্রয়োজনীয় আকারে ডাটাবেস আকার প্রসারিত করতে পারেন।

আপনি এসএসআইএসকে ডেটাবেস থেকে অন্য ডাটাবেসে স্থানান্তর করার উপায় হিসাবে বিবেচনা করতে পারেন। আপনি একটি অনুলিপি ডাটাবেস টাস্ক খুঁজে পাবেন যা আপনাকে সাহায্য করবে। আপনি নিম্নলিখিত পদক্ষেপগুলি ব্যবহার করতে পারেন:

উত্স ডাটাবেসের চেয়ে ছোট আকারের সাথে নতুন ডাটাবেস তৈরি করুন
স্থানান্তর ডাটাবেস টাস্ক সহ এসএসআইএস প্যাকেজ সেটআপ করুন। অনলাইন স্থানান্তর ব্যবহার করতে টাস্কটি সেট করুন।
এসএসআইএস প্যাকেজ চালান।
এসএসআইএস প্যাকেজটি উত্স ডাটাবেসের আকারের সাথে মেলে ডাটাবেসের আকার পরিবর্তন করতে পারে। এই ডাটাবেসটি সঙ্কুচিত করুন, কারণ এটির চেয়ে ছোট ফাইলের আকারের আকার রয়েছে।

এসএসআইএস স্থানান্তর ডাটাবেস টাস্ক সম্পর্কে অতিরিক্ত তথ্য দেখুন ।

— bobs
সূত্র

0

ডাটাবেসের কিছু অব্যবহৃত স্থান স্বাভাবিক।
আপনার যদি অনেক বড় রেকর্ড থাকে (বলুন, দীর্ঘ স্ট্রিং) থাকে তবে ডেটা পৃষ্ঠাগুলিতে অনেক অব্যবহৃত স্থান থাকতে পারে (কারণ একটি রেকর্ড সাধারণত পৃষ্ঠাগুলির মধ্যে বিভক্ত হয় না)।
আর একটি জিনিস একটি ফিল ফ্যাক্টর - প্রাথমিকভাবে, পরবর্তী সন্নিবেশগুলিতে পৃষ্ঠা বিভাজন (একটি ব্যয়বহুল ক্রিয়াকলাপ) এড়াতে ক্লাস্টারযুক্ত সূচকগুলি 100% পূর্ণ তৈরি হয় না।
যদি ডাটাবেস থেকে প্রচুর ডেটা মুছে ফেলা হয়, তবে এই ডেটাগুলির দ্বারা পূর্বে দখল করা স্থানটি স্বয়ংক্রিয়ভাবে পুনরুদ্ধার করা হবে না - এটি সারণীতে বরাদ্দ থাকবে।

DBCC DBREINDEX (table_name, '', 100)আপনার ডাটাবেসের প্রতিটি টেবিলে কল করার চেষ্টা করুন - এটি 100% পূরণের ফ্যাক্টর সহ সমস্ত সূচী পুনর্নির্মাণ করবে, তাই ডেটা যতটা সম্ভব কমপ্যাক্টভাবে স্থাপন করা হবে। তারপরে আবার ডাটাবেস সঙ্কুচিত করার চেষ্টা করুন।

— VladV
সূত্র

0

আমি আবিষ্কার করেছি যে একটি এসকিউএল সার্ভার ডাটাবেস সঙ্কুচিত করা ঝামেলা হতে পারে। মনে হচ্ছে আপনি একটি গান এবং নাচের রুটিন করতে পেরেছেন।

এই প্রক্রিয়াটি আমি সাধারণত:

ব্যাকআপ সঙ্কুচিত ডাটাবেস ব্যাকআপ সঙ্কুচিত লগ এবং ডাটাবেস ফাইল পৃথকভাবে। অবশেষে সঙ্কুচিত না হওয়া পর্যন্ত ব্যাকআপ পুনরাবৃত্তি করুন।

শেষ পর্যন্ত কাজ করার জন্য আমাকে এই প্রক্রিয়াটি কয়েকবার তিনবার পর্যন্ত করতে হয়েছিল। আমাদের GB৮ গিগাবাইটেরও বেশি আকারের একটি ডাটাবেস রয়েছে, যার মধ্যে 98% অব্যবহৃত স্থান রয়েছে। এই গান-ও-নাচের নিয়মিত বেশ কয়েকবার পেরিয়ে গেলেও শেষ পর্যন্ত এটি সঙ্কুচিত হয়ে ১ জিবি এর নিচে চলে যায়।

0

আমি এমডিএফ ফাইলের প্রাথমিক আকারটি প্রথমে ২৯,০০০ এমবি করে কমিয়ে হিট সনাক্ত করার পরে ২৮,০০০ করে নেওয়ার চেষ্টা করতাম।

30% ডেটা মুছে ফেলে ডাটাবেস ফাইলের আকারে 30% হ্রাস করা আশা করা অযৌক্তিক।

আপনার ডাটাবেসে কত অব্যবহৃত স্থান আছে তা আপনি অনুমান করতে পারেন

execute sp_spaceused

আপনার ডাটাবেসের পরিপ্রেক্ষিতে (yourdatabaename ব্যবহার করুন;)
আপনি কি তার কার্যকর ফলাফল পোস্ট করতে পারেন?

আপডেট:
আমি এটিতে আমার সম্পর্কিত প্রশ্ন পোস্ট করেছি:

সংক্ষেপণ, ডিফ্র্যাগমেন্টেশন, স্থান পুনরুদ্ধার, সঙ্কুচিতকরণ বনাম সঙ্কুচিত ফাইল

— গেনাডি ভ্যানিন Геннадий Ванин
সূত্র

এটি খুব ভাল কাজ করে না। 13903.16mb অব্যবহৃত স্থান। অব্যবহৃত সূচক 1688944 KB