ما ۴ تا name در دیتابیس داریم که از اول هر ۴ تای این اسامی در دیتابیس اوراکل نبوده‌اند و به مرور نسخه‌های مختلف و زمان ایجاد شده‌اند.
ORACLE_SID (در سطح OS) = این پارامتر در سطح OS ما است. اگر پارامتر db_name مقداردهی نگردند مقدار این پارامتر را می‌گیرد.
DB_NAME (اجباری، یکسان باشد*) = اسم دیتابیس و به معنای کلمه جایی که دیتاها ذخیره می‌شوند. عمیقاً کلمه دیتابیس به ۳ دسته از فایل‌ها گفته می‌شود:
۱) دیتافایل‌ها ۲) فایلهای ORL, CTL, SPFILE منظور DB_NAME فایلهای دیتابیس است که مجزا از Instance هستند.
ORACLE DB_NAME PARAMETER V11.2 - LINK
db_name در دیتابیسهای مختلف در یک ماشین می‌تواند تکراری باشد و می‌تواند تکراری نباشد. توصیه میشه اگر چند دیتابیس در یک ماشین دارید db_name های آنها را باهم تکراری انتخاب نکنید.
پارامتر db_name و db_domain از قدیمی‌ترین پارامترهای اوراکل هستند و از نسخه‌های اول در دیتابیس اوراکل بوده‌اند
ORACLE PARAMETER FILE V7.3.4 - LINK
۲ پارامتر db_name و db_domain هر دو قبل از ایجاد دیتابیس تنظیم می‌شوند و بعد از تنظیم مقادیر آنها و تشکیل Instance مقادیرشان به راحتی قابل تغییر نخواهد بود
ORACLE PARAMETER DB_NAME V8.0.4 - LINK
این پارامتر به صورت mandatory (الزامی) در تشکیل Instance است و باید در سناریو دیتاگارد در همه طرف‌ها با هم یکی باشد.
نکته: این پارامتر اجباری است و اگر مقداردهی نگردد مقدار آن از پارامتر ORACLE_SID در سطح OS گرفته می‌شود. همچنین اگر هر کدام از ۳ پارامتر بعدی مقداردهی نگردند مقدار آنها از مقدار این پارامتر مقداردهی می‌گردد.
DB_UNIQUE_NAME (اجباری، یکسان نباشد*) = وقتی ما چند دیتابیس در یک سرور داریم و یا چند دیتاگارد برای یک ماشین primary داریم(در سناریو گارد db_nameهای همه این دیتابیسها با هم یکی هستند چون در یک خانواده و یا مدار بیزنسی باهم در حال سرویس‌دهی هستند (دیتابیس primary و تمام standbyهای آن به هم وابسته اند چون همه چیز دیتابیس اصلی با دیتابیسهای گارد باید یکی باشد) در نهایت تمام گاردها و دیتابیس primary دارند دسترسی به اطلاعات دیتابیس x را سرویس‌دهی می‌کنند.) به این دلیل پارامتر db_unique_name به دیتابیس اوراکل 10g اضافه گردید تا در یک خانواده و یا مدار بیزنسی دیتابیسها از هم قابل تشخیص باشند.
ORACLE PARAMETER DB_UNIQUE_NAME V10.1 - LINK
این پارامتر در زمانی که شما DB_NAME و DB_DOMAIN یکسان در چند دیتابیس در یک ماشین و یا سناریو گارد را دارید به صورت mandatory (الزامی) است، در سناریو دیتاگارد باید در همه طرف‌ها مقداردهی گردد و به صورت یکسان نباشد.
SERVICE_NAME (اختیاری* - نامگذاری براساس بیزنس) = Listener از اینجا وارد معماری پارامترهای اوراکل می‌شود. pmon وقتی میخواد دیتابیس رو برای Listener ریجیستر کنه چندتا پارامتر رو بررسی میکنه از جمله اون پارامترها: Local_Listener یا OLR (و Remote_Listener) است که به pmon میگه کجا ریجیستری سرویسها اتفاق بیوفته(با کدام protocol، کدام ip و portها)، یکی دیگه از پارامترها service_name هستش که مشخص میکنه چه سرویسهای باید در Listenerها توسط pmon ریجستر شوند. پارمتر service_name به طور کلی سرویسهایی که دیتابیس ما ارائه می‌دهد را مشخص می‌کند.
مثال از کاربرد این پارامتر: وقتی سازمان ما روی یک دیتابیس schemaهای مختلف برای سامانه‌های مختلف داره برای ایجاد تفکیک LOG و بهبود شبکه DBA ما میتونه service_nameهای مختلفی ایجاد کنه که بتونه برای هر سامانه Listener متفاوتی در سطح سرور(با ریجستری استاتیک یا داینامیک بسته به سیاست DBA) ایجاد کنه که درخواستهای همه سامانه‌ها روی یک Listener نباشد و ترافیک شبکه‌ای تفکیک و پخش شود. (برای این که این تفکیک بهترین تاثیر رو داشته باشه تو هر لایه شبکه‌ای باید تفکیک انجام بشه NIC, IP, Port, Service_name)
یا بازم فرض کنید ما یک دیتابیس در یک سرور داریم و نیاز داریم اپلیکیشن سرورهای مختلف هر کدام به دیتابیس وصل شوند(سرور اپلیکیشن مالی، سرور اپلیکیشن اداری و ...) چون اولویت بیزنسی این اپلیکیشن‌ها با هم فرق داره (مثلا کار مالی مهم‌تر از هر چیزی میتونه باشه) زمان اتصال و سرویس‌دهی دیتابیسهای اونها نیز میتونه با هم فرق داشته باشه پس بهتره Listener اونها در سطح سرور جدا حتی از لحاظ port باشه.
پارامتر service_name اختیاری است و از زمانی که معماری Grid Computing به اوراکل اضافه گردید به لیست افتخارات پارامترهای 10g شد.
این پارامتر کاملاً به صورت Optional یا اختیاری است. ولی یه مزیتی در سناریو دیتاگارد در این پارامتر وجود دارد که اگر بین دیتابیسها یکی باشد وقتی روزی switchover یا failover ای در دیتاگارد رخ بدهد نیازی نیست connection stringها به service_name جدید تغییر پیدا کنند مگر اینکه از TAF استفاده کرده باشید.
نام service_name به طور معمول از روی بیزنس اپلیکیشن‌ها گرفته می‌شود.
ORACLE PARAMETER SERVICE_NAMES - LINK
نکته: موقع پیکربندی دیتاگارد از اونجایی که هر ۲ دیتابیس دارند سرویس‌دهی رو برای یکسری از اپلیکیشن‌ها ارائه می‌دهند ما یک dns name برای ip دیتابیس primary ایجاد می‌کنیم و dns name را در اختیار اپلیکیشن‌ها قرار می‌دهیم تا اگر روزی switchover یا failover رخ داد تنها با تغییر ip پشت dns (در صورت یکی بودن service_nameها) اپلیکیشن یا اپلیکیشن‌ها به دیتابیس ما به طور خودکار وصل شود.
INSTANCE_NAME (اختیاری*، نامگذاری براساس جغرافیا و عدد) = اگه ما سناریو Cluster دیتابیس اوراکل رو پیاده‌سازی کرده باشیم (ORACLE RAC) این پارامتر باید مقداردهی گردد. در یک محیط RAC ما چند Instance داریم که در حال سرویس‌دهی به یک دیتابیس هستند. کلاینتها با مشخص کردن نام هر Instance می‌توانند موقع اتصال فقط به Instance مورد نظر خودشون متصل شوند. مثلا ما یک RAC داریم که از ۴ نود تشکیل شده حالا کلاینتهایی که نیاز به ریپوتی سنگین و محاسباتی در لحظه دارند رو می‌تونیم به Instace ای که خلوت‌تر هستش متصل کنیم.
در یک محیط Single-Instance معمولاً مقدار این پارامتر برابر با database name یا db_name ما است.
اگر این پارامتر مقدار دهی نشود مقدار پارامتر db_name پیش‌فرض آن است.
نکته ۱
وقتی شما software اوراکل را به صورت software only نصب کنید، قبل از ایجاد دیتابیس با ابزار DBCA (این ابزار هم Instance را ایجاد می‌کند و هم Database را) می‌توانید با اجرای startup nomount force یک Instance با مقادیر Default ایجاد کنید.
نکته ۲
هر software می‌تواند n دیتابیس در مسیرهای مختلف و جدا از هم داشته باشد. برای ایجاد چند دیتابیس در یک software oracle از ابزار DBCA استفاده می‌کنیم و مسیرهای مختلفی را برای هر دیتابیس ایجاد می‌کنیم. (دیتابیس اداری، دیتابیس منابع انسانی، دیتابیس مالی، دیتابیس مشتریان و ...)
نکته ۳
در یک ماشین می‌توان چند software از نسخه‌های مختلف نصب و پیکربندی کرد. به عنوان مثال در یک مسیر 11g و در یک مسیر 12c
لینکهای مفید
https://aprakash.wordpress.com/2011/03/25/oracle-local-registry-olr-11gr2
https://en.wikipedia.org/wiki/Oracle_Database
https://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams095.htm#REFRN10082
https://docs.oracle.com/cd/B12037_01/server.101/b10755/initparams175.htm
https://mdinh.wordpress.com/2016/08/18/configuring-multiple-local_listener