عوض کردن DB_NAME دیتابیس با استفاده از NID

یکی از مشکلاتی که ممکنه براتون پیش بیاد اینه که بعد از ساخت دیتابیس جدید بخواین به هر علتی DB_NAME رو به مقداری دیگه تغییر بدید

درسته که تغییر DBID با nid، اثرات غیرقابل برگشتی روی توانایی‌های بک‌آپ و ریکاوری داره، اما تغییر DB_NAME دیتابیس به‌طور چشمگیری پیامدهای کمتری داره، چون:

  1. بک‌آپ‌هایی که قبلاً گرفته شده‌اند را بی‌اعتبار نمی‌کنه
  2. آرشیولاگ‌هایی که قبلاً ساخته شده‌اند را بی‌اعتبار نمی‌کنه
  3. به open کردن پایگاه داده به وسیله‌ی ریست‌لاگ نیازی نداره

خب بیایید db_name پایگاه داده را بدون تغییر dbid دیتابیس تغییر بدیم. (نکته: در هر حال باید حواستان به اثرات احتمالی هم باشه) 

SQL> shutdown immediate;
Database dismounted.
ORACLE instance shut down.

ادامه مطلب...
۰۶ شهریور ۹۵ ، ۲۲:۳۴ ۰ نظر
مهدی غفاری

نگاهی بر معماری Oracle Data Guard - قسمت اول

تو این مجموعه پست‌ها میخوایم نگاهی مقدماتی بر اوراکل دیتاگارد از روی اسلایدهای اوراکل داشته باشم:

 

بعد از کامل کردن این سری از اسلایدها شما قراره:

  • کامپوننت‌ها و اجزای دیتاگارد رو بشناسید
  • اختلاف بین physical standby و logical standby رو بدونید
  • فواید پیاده‌سازی دیتاگارد رو بشناسید

نکته: کلاً وقتی دیتاگارد راه میندازیم یعنی ۲ تا سرور داریم یکی سرور اصلی primary و یکی سرور دیتاگارد که بهش standby می‌گیم (چون همیشه آماده به خدمته)

ادامه مطلب...
۲۳ مرداد ۹۵ ، ۱۷:۱۸ ۳ نظر
مهدی غفاری

تغییر اسم اینترفیس شبکه لینوکس از طریق udev

مثلاً فکر کنید سیستم‌عامل ما کارت شبکه رو با اسم wlan0 شناخته ولی ما میخوایم اسم رو به wl0 تغییر بدیم یا بعد از clone گیری از ماشین مجازی تو محیط‌های مجازی‌ساز ممکنه براتون این مشکل پیش بیاد که کارت شبکه‌های ماشین قدیمی تو فایلهای config باقی مونده باشه و سیستم‌عامل شما کارت شبکه‌های جدید رو با شماره‌های بعدی اسم گذاری کرده باشه این در حالیه که موقع راه‌اندازی کلاستر اوراکل اسم اینترفیس‌های شبکه باید یکسان باشند

خب بهترین روش برای عوض کردن اسم دیوایس‌ها از طریق udev ه (udev یه دیوایس منیجر برای کرنل لینوکس‌ه)

در ابتدای راه‌اندازی udev سخت‌افزارها رو میشناسه و براشون طبق استاندارد اسم گذاری میکنه و هر دیوایس رو به صورت یک فایل زیر dev/ قرار میده. udev به طور کلی جانشین devfs و hotplug شده البته هر کدوم از اینها میتونن دیوایس‌ها رو در دایرکتوری dev/ مدیریت کنند و تمام رفتارهای user space کرنل رو بسنجن تا وقتی یک دستگاه جدید add یا remove (به صورت hotplug یا به هر صورت دیگه‌ای) میشه firmware دستگاه رو لود کنند.

نام‌گذاری و مرتب‌سازی کارت‌های شبکه به طور غیر قابل پیش‌بینی اتفاق در هر reboot اتفاق میوفته در کرنل‌های جدید هم اسم‌گذاری کارت‌های شبکه به طور کامل تغییر کرد.

مرحله اول: پیدا کردن MAC آدرس کارت‌های شبکه

# ifconfig -a | grep -i --color hwaddr

مثالی از خروجی:

eth0      Link encap:Ethernet  HWaddr b8:ac:6f:65:31:e5
pan0      Link encap:Ethernet  HWaddr 4a:71:40:ed:5d:99
vmnet1    Link encap:Ethernet  HWaddr 00:50:56:c0:00:01
vmnet8    Link encap:Ethernet  HWaddr 00:50:56:c0:00:08
wlan0     Link encap:Ethernet  HWaddr 00:21:6a:ca:9b:10

MAC آدرس‌ها رو یادداشت کنید.

مرحله دوم: تغییر نام کارت شبکه

برای عوض کردن اسم eth0 به wan0 باید فایل 70-persistent-net.rules رو تو مسیر /etc/udev/rules.d/ پیدا و ویرایش کنید:

# vi /etc/udev/rules.d/70-persistent-net.rules

اسم کارت‌های شبکه ماشین شما در این فایل لیست شده، دنبال خطی باشید که میخواین ویرایشش کنید:

# PCI device 0x14e4:0x1680 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:ac:6f:65:31:e5", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

تو این مثال ما میخوایم اسم eth0 رو به wan0 تغییر بدیم پس تو آخر خط "NAME="eth0 رو با "NAME="wan0 عوض می‌کنیم.

# PCI device 0x14e4:0x1680 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:ac:6f:65:31:e5", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="wan0"

حالا فایل رو save کنید و ماشین رو reboot کنید.

تنظیمات جدید رو ببینید:

# ifconfig -a
# ifconfig wan0
# ifconfig -a | less
# ip addr show

همچنین اگه بعد از reboot و طی بررسی‌هاتون دیدید که فایلی برای اینترفیستون توی مسیر /etc/sysconfig/network-scripts/ وجود نداره یک فایل با نام اینترفیس مثلاً ifcfg-eth0 با مقادیر زیر بسازید:

DEVICE=eth0
HWADDR=08:00:27:76:74:BD
TYPE=Ethernet
#UUID=540e14f4-907c-4bb9-9f59-e5e45c64414d
ONBOOT=no
NM_CONTROLLED=yes
BOOTPROTO=dhcp

منبع

۱۸ تیر ۹۵ ، ۰۰:۴۶ ۱ نظر
مهدی غفاری

charcter setهای دیتابیس برای داده فارسی

  • AR8MSWIN256
  • AL16UTF8
  • AL32UTF8
  • UFT8

AR8MSWIN256

نکته: قدیمها به جای AR8MSWIN256 از WE8ISO8859P1 استفاده میکردن بدون اینکه دلیلش رو بدونن، در حقیقت این استاندارد قبل از اومدن AR8MSWIN256 رواج داشت ولی دیگه قابل قبول نیست

AR =همون Arabic

تو ویندوز XP اگه به قسمت Regional and Language Option برید تو قسمت Code page conversion table استاندارهای ذخیره کاراکترها رو می‌بینید (تو ویندوز اگه اسکرول کنید بیاین پایین استاندارد 1256 (ANSI - Arabic) رو می‌بینید)

تو این استاندارد ذخیره‌سازی به غیر از حروف عربی ۴ حرف اضافه فارسی هم اضافه شده (گچ پژ)

8 = یعنی ۸ بیت (۱ بایت)

نکته: ۱ بایت همیشه ۸ بیت نبود تو یونیکس‌های قدیمی ۱ بایت ۷ بیت بود

MS = مخفف Microsoft

WIN = مخفف Windows

256 = به همون 1256 اشاره داره

نکته: پس اگه دیتابیستون رو روی charcter set: AR8MSWIN256 بذارید هر کاراکتر ۱ بایت‌ه پس اگه بگیم (20)varchar2 ما می‌تونیم ۲۰ تا کاراکتر تایپ کنیم

AL16UTF8

AL = همون Alternative

16 = یعنی ۱۶ بیت یا همون ۲ بایت

پس هر کاراکتر AL ما ۲ بایت میگیره

پس اگه ما یکبار 'mahdi' رو به صورتی انگلیسی تایپ کنیم ۵ بایت اشغال میشه

و برای 'مهدی' ۸ بایت اشغال میشه

AL32UTF8

AL = همون Alternative

32 = یعنی ۳۲ بیت یا همون ۴ بایت

پس هر کاراکتر AL ما ۳۲ بایت میگیره

پس اگه ما یکبار 'mahdi' رو به صورتی انگلیسی تایپ کنیم ۵ بایت اشغال میشه

و برای 'مهدی' ۱۶ بایت اشغال میشه

UFT8

utf8 برای همه نوع کاراکتر ۳ بایت اشغال میکنه

پس وقتی از char موقع ایجاد جدولتون استفاده می‌کنید دقیقاً بسته به character set دیتابیستون شما کاراکترها رو مشخص می‌کنید

مثلاً اگه بگید:

varchar2(20) char => دقیقاً 20 کاراکتر میشه در این فیلد ذخیره کرد حالا بسته به character set دیتابیس ممکنه هر حرف رو ۲ بایت، ۳ بایت، ۴ بایت در نظر بگیره

برای آشنایی بیشتر با character setها به سایت http://unicode.org سر بزنید.

همچنین خوبه به این مستند مایکروسافتی هم سر بزنید.

۰۵ تیر ۹۵ ، ۱۶:۳۵ ۰ نظر
مهدی غفاری

انواع Data Type در Oracle Database 11g

  • varchar استاندارد ANSI داره
  • varchar2 استاندارد oracle رو داره (ماکزیمم 4000 بایت تو 11g و 32767 بایت تو 12c)
  • char به صورت ماکزیمم 255 بایت یا کاراکتر رو ساپورت میکنه
  • nvarchar2 به صورت ماکزیمم 2000 بایت یا کاراکتر
  • number به صورت ماکزیمم ۳۸ رقم
  • date شامل "قرن، سال، ماه، روز، ساعت، دقیقه، ثانیه" داره
  • timestamp تمام date رو داره بعلاوه اینکه ثانیه تا ۹ رقم ریزتر هم میشه
  • long برای کاراکتر استفاده میشه و ماکزیمم اون ۲ گیگ‌ه
  • long raw برای فایلهای باینری هستش و برای فایل‌های pdf, doc, mp3, avi, dll, ... هستش ماکزیمم ۲ گیگ

LOBs یا همون Large Objects

  • clob به صورت کاراکتره و ماکزیمم ۴ گیگ‌ه
  • nclob به صورت کاراکتر با ساپورت کاراکترهای national و ماکزیمم ۴ گیگ‌ه
  • blob به صورت binary برای فایلهای باینری هستش و برای فایل‌های pdf,rtf, doc, mp3, avi, dll, ... هستش، ماکزیمم ۴ گیگ
  • bfile در این type فایل‌ها به صورت اکسترنال و روی OS قرار داردند و درون bfile اشاره‌گر به فایل قرار دارد، ماکزیمم ۴ گیگ
  • securefile همون blob با سرعت و کارایی بیشتر

تفاوت بین long و long raw و LOBها

1:

اگه فیلدهای جدول شما به صورت زیر باشه به طور قطع شما موقع ساخت جدول به مشکل میخورید:

create table e(
e_id number(20),
f_name varchar(40 char),
...,
...,
cv long,
img long raw
);

نکته اینجاست که در یک جدول ۲ فیلد long نمیتوان داشت

2:

سرعت خوندن در log و LOBها متفاوته

در حقیقت long و long raw به صورت sequencial از حافظه میخونن(سریالی) و LOBها به صورت random access(مستقیم)

3:

در اوراکل با contex index یا همون oracle text میشه فیلدهای blob رو به صورت لغت به لغت ایندکس‌گذاری کرد همچنین به طور کامل از فارسی پشتیبانی میکنه

نکته: روز فیلدهای blob و clob نمیتوان index معمولی (b-tree ,bitmap) گذاشت

نکته: اگه فایل pdf داشته باشید context index نمیتونه فارسی‌ها رو ایندکس بکنه و فقط انگلیس‌ها رو ایندکس میکنه

4:

ذخیره فایلهای باینری مثل فیلم و موزیک در bfile عملکرد بهتری نسبت به فقط ذخیره آدرس فایل در varchar یا ... دارد

مثلا فرض کنید OS ما ویندوزه و فایلهای ما هم در درایوهای ویندوز قرار داره پس موقع ذخیره آدرس فایل در varchar آدرس فایلها به صورت ویندوزی است در این حالت اگه مسیر فایلها رو عوض کنیم کل مسیرهای ذخیره شده در دیتابیس هم باید عوض شود همچنین اگه سیستم‌عاملمون رو عوض کنیم و به unix baseها یا unix likeها که از استاندارد POSIX استفاده میکنن بریم دوباره کل مسیرها باید عوض شوند تازه اگه فایلها تو انتقال طبقه‌بندی و از هم جدا بشن درست کردن مسیرها بسیار کار مشکلی خواهد بود

برای رهایی از این مشکلات از bfile استفاده می‌کنیم و با ایجاد یک آبجکت دایرکتوری در دیتابیس مسیر فایلها رو ذخیره می‌کنیم در این رویکرد اگه سیستم‌عامل عوض شود یا بخوایم مسیر رو عوض کنیم فقط مسیر دایرکتوری رو عوض می‌کنیم

مزیت دیگه bfile نسبت به varchar برای ذخیره آدرس فایلها اینه که میتونیم رو فایلها ایندکس بذاریم(مثلا ایندکس روی doc, docx, rtf, ...) در صورتی که اگه از نوع varchar باشه فقط روی رشته‌ها ایندکس انجام میشه

اگه blob رو به bfile ببریم اولین مشکل میتونه تو خراب شدن پسوند فایلها در OS به وجود بیاد، دومین مشکل سر export گیری هستش اگه فایلها توی blob باشن با یه export تمام فایلها هم بک‌آپ گرفته میشن همچنین حجم بک‌آپ بالاتر میره

char

وقتی از data type char استفاده می‌کنید داده‌ها تو حافظه به صورت fix ذخیره می‌شوند

(پس سایز char به صورت fix ‌است) مثلاً:

Mahdi char(20) => 'Mahdi              '

مشکلات char

  • اشغال زیاد حافظه
  • مشکل در index و sort
  • مشکل در select (حتما باید موقع select ما trim کنیم رشته ورودی رو)
create table employees(
    employee_id number(10),
    f_name varchar2(40 char)
)

تو فیلد اول type ما در حقیقت 10 بایت‌ه و تعداد کاراکترهاش بسته به character set دیتابیس داره

و تو فیلد دوم type ما دقیقاً 40 کاراکتره

۰۵ تیر ۹۵ ، ۱۳:۲۳ ۰ نظر
مهدی غفاری

نگاهی بر معماری Oracle Database 11g - قسمت سوم

نگاهی بر معماری Oracle Database 11g - قسمت اول

نگاهی بر معماری Oracle Database 11g - قسمت دوم

LGWR

کار background process log writer اینه که تمام redo entryها رو که توی log buffer نوشته میشه رو توی redo log file بنویسه

LGWR تعداد نداره یعنی همیشه یکی است و اگه این background process پایین بیاد دیتابیس کلاً shutdown میشه

زمانهای نوشتن:

  • اگر کاربر دستور commit رو بزنه
  • وقتی که 1/3 redo log buffer پر بشه
  • قبل از شروع نوشتن بافر در دیسک توسط DBW
  • هر ۳ ثانیه یکبار

سرعت نوشتن LGWR بسایر بیشتر از DBW ه چون فقط به انتهای یک فایل باینری redo entryها رو میبره

LGWR به صورت چرخشی بین redo log file ها عمل میکنه که بهش log witch میگیم

ادامه مطلب...
۰۱ تیر ۹۵ ، ۱۳:۲۲ ۰ نظر
مهدی غفاری

نگاهی بر معماری Oracle Database 11g - قسمت دوم

نگاهی بر معماری Oracle Database 11g - قسمت اول

KEEP buffer pool

اگه جداول base ما در محاسباتمون زیاد استفاده میشه (موقع join ها) و گزارش‌گیری‌های زیادی ازشون انجام میشه برای اوراکل نمیصرفه هر دفعه اطلاعات شما رو بیاره تو database buffer cache پس اوراکل جدول رو KEEP میکنه یعنی جدول base رو میخونه میاره تو حافظه تو محفظه‌ی KEEP buffer pool پس دیتایی که دائما توی گزارش‌هامون مورد استفاده قرار میگیره و تغییراتی روش انجام نمیشه رو اوراکل به صورت KEEP نگه میداره مگر اینکه دیتابیس بیاد پایین یا برق سرور بره

همچنین این کار موقع ساختن جدول یا بعدش با دستور alter امکان پذیره همچنین می‌تونید برای اینکار اسکریپت هم بنویسید

 Alter table emp storage (buffer_pool Keep);

یه نمونه اسکریپت

Oracle Automating Script for KEEP Pool Caching Tables & Indexes db_keep_cache_size

BEST PRACTICE اینه که فقط جداول پایه با حجم کم رو KEEP‌ کنید در کل جداولی با داده کم و کاربرد زیاد مثل اطلاعات: شهرها، فرمولهای مالی، نرخ سود، نام دپارتمان‌ها و ...

 

نکته: هیچوقت یک جدول بالای 1 میلیون رکورد رو KEEP نکنید چون بی‌خودی حافظه رو میگیره

نکته: اگه دیتا زیاده و تغییرات داره بهتره از TimesTen استفاده بشه (این محصول دیتا رو کلاً میخونه میذاره تو حافظه بعد خودش دیتابیس رو مدیریت میکنه که اگه دیتا تغییر کرد دیتای حافظه هم تغییر کنه و ...)

ادامه مطلب...
۳۱ خرداد ۹۵ ، ۲۳:۰۶ ۲ نظر
مهدی غفاری

نگاهی بر معماری Oracle Database 11g - قسمت اول

تو این پست میخوایم نگاهی دوباره بر معماری اوراکل از روی اسلایدهای دانشگاه اوراکل بندازیم.

دریافت
حجم: 558 کیلوبایت
توضیحات: Less01_Architecture

دریافت
حجم: 23 مگابایت
توضیحات: تمام اسلایدهای اوراکل ورکشاپ ۱ به همراه اسکریپت‌ها 

نگاهی بر معماری Oracle Database 11g - قسمت اول

نگاهی بر معماری Oracle Database 11g - قسمت دوم

نگاهی بر معماری Oracle Database 11g - قسمت سوم

یادتون باشه اگه معماری اوراکل رو خوب ندونید برای tuning اون نمیتونید مانور زیادی انجام بدید. پس اول باید معماری رو خوب بلد باشیم که چه اتفاقهایی تو سیستم میوفته بعد برای tun‌ کردن دیتابیس اقدام کنیم.

ادامه مطلب...
۰۳ خرداد ۹۵ ، ۱۱:۰۴ ۴ نظر
مهدی غفاری

اتصال Oracle به SQL Server با Oracle Database Gateway

با اومدن ورژن 11g، اوراکل محصول جدیدی رو به عنوان Database Gateway معرفی کرد که میتوان از آن برای اتصال به MSSQL و دیتابیس‌های مختلف دیگه استفاده کرد.

Database Gateway با ورژن‌های 10.1.0.5، 10.2.0.3 بعد از اعمال patchهای امنیتی سازگاره همچنین به طور مستقیم با ورژن‌های 10.2.0.4، 10.2.0.5، 11.1 و 11.2 مشکلی نداره

مراحل زیر رو دنبال کنید و یادتون باشه این مراحل روی پلتفرم‌های Linux/Unix کار میکنه البته برای باقی سیستم‌عامل‌ها هم مراحل شبیه همین مراحل‌اند:

  1. اگه قبلاً Oracle Database Gateways رو دانلود نکردید تو قدم اول باید دانلود رو انجام بدید.
  2. Oracle Database Gateway رو برای Microsoft SQL Server نصب کنید.
  3. Database Gateway رو برای اتصال به Microsoft SQL Server کانفیگ کنید (DG4MSQL).

دانلود نرم‌افزار

Oracle Database Gateways رو از Oracle eDelivery یا Metalink دانلود کنید.

ادامه مطلب...
۲۴ ارديبهشت ۹۵ ، ۱۶:۲۵ ۲ نظر
مهدی غفاری

انتقال فایل به دیسک‌های ESXi از طریق vSphere Client

برای انجام اینکار بعد از ورود به vsphere روی storageامون راست کلیک می‌کنیم و Browse Datastore رو انتخاب می‌کنیم

ادامه مطلب...
۲۲ ارديبهشت ۹۵ ، ۱۹:۱۸ ۱ نظر
مهدی غفاری