برای انجام اینکار می‌توان به فرم کلی زیر اینکار را انجام داد:
alter tablespace <tablespace_name> add datafile <url> size <size>;
مثال:
alter tablespace ts add datafile 'd:\root\b.dbf' size 100m;
نکته: مسیر tablespace شما می‌تواند در شبکه نیز باشد. حتی می‌تونه تو درایوهای دیگر و هر نوع مدیای ذخیره‌سازی نظیر: هارد اکسترنال، فلش، رم و ... باشد.
نکته: اگر هر کدوم از DataFileهای ما از شبکه خارج شوند یا از حالت mount بیرون بیایند موقع start کردن اوراکل به مشکل جدی می‌خورید و اورکل تا همه DataFileهای مد نظر را نداشته باشد دیتابیس را startup open نمی‌کند.(به صورت کلی باید DataFile همیشه باشد و بدون نبود DataFile به هیچ‌وجه نمی‌توان دیتابیس را startup open کرد برای همین پیشنهاد می‌کنم که همیشه Backup داشته باشید)
نکته: در این موارد بهترین کار flash recovery است.
نکته: اگر بخواهید یک table را روی چند tablespace پراکنده کنیم باید حتماً partitioning کنید و جالبه بدونید که قبل از ورژن 11g اوراکل اجازه اینکار را اصلاً نمی‌داد چون اصلاً بحث partitioning مطرح نبود.
س: چرا وقتی می‌توان چند DBF را به یک TableSpace اضافه کرد باید از چند TableSpace برای ذخیره‌سازی یک جدول استفاده کرد؟
ج: به خاطر سرعت index گذاری و cache اولیه - مثلاً وقتی می‌گیم select * from person where age =20 اوراکل به صورت پیش‌فرض اصلاً به where شما گوش نمی‌دهد اما حالا فرض کنید فضای SGA فضای کافی نباشه که بتونه کل جدول رو لود کنه (این مثال در مورد جداول بسیار بسیار حجیم صحت دارد مثلاً جدول ۱ اگزابایتی) خب شما نمی‌تونید رم ۱ اگزابایتی پیدا کنید که کش رو تو فضای SGA انجام بده پس کش کامل انجام نمیشه و همونطور که قبلاً گفتم اوراکل در این مورد خورد خورد عمل میکنه و تیکه تیکه دیتا رو برای کش میاره و در این حالت وقتی میخواد بره تیکه تیکه بیاره وقتی میبینه اندازه کش کافی نیست به سرعت میره و فقط اون قسمت where رو پیدا میکنه و کش میکنه و شما اگه partitioning اتون رو بر مبنای age کرده باشید اوراکل به سرعت اون DataFileرو پیدا میکنه و کش میکنه به این حالت میگن (کش اولیه یعنی زمانی که میخواد برای بار اول کش رو انجام بده)
یعنی زمانی که برای کش فضای خالی به اندازه کافی نباشد اوراکل به where شما توجه می‌کند و از partitioning به نفع خودش استفاده می‌کند تا به دیتا فایلی برسد که داده ما درون آن است.(این فقط در مورد tableهای وحشتناک سنگین صدق می‌کند)
س: چه زمانی کش اولیه زیاد انجام میشه؟
ج: زمانی که در فضای SGA فضای کافی برای کش کل Table نداریم.
نکته: تو مبحث partitioning اول باید به این نکته توجه کنیم که نوع سیستم اپلیکیشنمون چیه؟ و براساس چه فیلد کلیدی اون سیستم گسترش پیدا میکنه؟ (مثلاً بر اساس شماره حساب، موجودیه، نام مشتریه و ...)
نکته: در مورد social network دید من به هیچ عنوان RDBMS و حتی ORDBMS نیست در این سیستم‌ها بهترین راهکار NoSQL است.
س: اگر یک جدول روی ۲ تا TableSpaceباشه چقدر فرگمنت در دیتافایل‌ها می‌گیره؟
ج: جدول تو حالت نرمال روی ۲ تا TableSpace قرار نمی‌گیره، اگر پارتیشن باشه می‌تونه قرار بگیره و فرگمنت در این حالت برای این جدول زیاد است. برای رکوردها با حج بالا یک جدول حتماً باید به چندین TableSpace وصل باشد. چون نگهداری به عنوان مثال ۱ اگزابایت اصلاً کار ساده‌ای نیست چون خوندن اون یه جدول آنقدر سنگین میشه که رو کش اولیه ۴۵ دقیقه فقط کش اولیه طول میکشه. حال زمان time out ای که ما توی بحث partitioning دیتافایلهامون داریم می‌چربه به اینکه partitioning نداشته باشیم و جدولمون روی یک TableSpace باشه چون یکدونه رو خیلی سختر میخونه تا چندتا رو
س: چرا در حالت بالا ترجیح می‌دهیم distribute کنیم؟
به خاطر وقتی selectمیزنیم کل DataFile نمیاد کش بشه چون فضای SGA محدوده میره به اون دیتافایلی که تو where است و اینجا قبل از کش به where توجه میکنه و میره دنبال DataFile ای که تو شرط where صادقه
س: partitioning چند حالت داره؟
ج: حالت هوشمند (TimeStamp) - براساس فیلد - براساس فیلد و نوع‌های مختلف دیگه به صورت مفصل در مطالبی جدا توضیح داده خواهد شد.
سلام بسیار عالی بود ممنون.