……….آموزش، مشاوره و پشتیبانی……….
در مبحث “آشنایی با Clustering Factor در اوراکل” مطالبی را در مورد CLUSTERING_FACTOR ارائه دادیم در این مطلب قصد داریم با چند مثال عملی را در این زمینه ارائه کرده و در پایان، هزینه استفاده از ایندکس را برای هر دو حالت با هم مقایسه خواهیم کرد.
مثال 1(CLUSTERING_FACTOR بد): قصد داریم با اجرای پرس و جوی زیر، اطلاعاتی از جدول badcftable را در خروجی نمایش دهیم:
SQL> Select * from badcftable where code=2;
قصد داریم از طریق یکی از ایندکسهای جدول، به تک تک رکوردهای آن جدول دسترسی پیدا کنیم به این صورت که ابتدا آدرس فیزیکی یا همان rowid رکورد را از طریق ایندکس پیدا کرده و سپس با انتقال Data Block حاوی آن رکورد به حافظه، جدول را scan کنیم.
از آنجایی که اطلاعات در ایندکس به صورت “مرتب” ذخیره می شوند، هر چه ترتیب قرار گرفتن رکوردها در جدول مشابه ترتیب قرارگیری keyها در ایندکس باشد، نیاز به I/O کمتری خواهیم داشت و SCAN جدول از طریق ایندکس می تواند با سرعت بیشتری انجام شود.
به عبارتی دیگر اگر در یک Leaf Block پنج index entry موجود باشد، در بهترین حالت هر پنج رکورد متناظر با index entryها، در یک Data Block قرار می گیرند و در بدترین حالت، هرکدام از این رکوردها در یک بلاک مجزا در جدول ذخیره شده اند.
با ارائه قابلیت Interval partitioning در اوراکل نسخه 11g، نیاز به اضافه کردن دستی پارتیشن، در هنگام درج اطلاعات خارج از محدوده از بین رفته است. در این متن به صورت خلاصه نکاتی را در مورد Interval Partitioning مرور خواهیم کرد.
پرسش: چگونه می توان مسیر فایلهای Logی که در var/log/ قرار دارند را به مسیر دیگری تغییر داد؟
پاسخ: مسیر فایلهای Log در لینوکس 8,RHEL 6,7، در فایل پیکربندی سرویس Rsyslog تنظیم می شوند:
[root@node1 ~]# grep “/var/log” /etc/rsyslog.conf
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* –/var/log/maillog
cron.* /var/log/cron
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
تغییر مسیر var/log/، با تعیین مسیر جدید در فایل rsyslog.conf قابل انجام است:
همانطور که می دانید، متغیر محیطی ORACLE_SID، نام instance اوراکل را مشخص می کند:
[oracle@Primary ~]$ echo $ORACLE_SID
sid
SQL> select INSTANCE_NAME from v$instance;
INSTANCE_NAME
—————-
sid
در این متن نکاتی را در مورد حداکثر طول کاراکتر ORACLE_SID و نام instance ارائه خواهیم کرد.
در زمان کار با ابزار netmgr، امکان استفاده از sid با طول بیشتر از 8 کاراکتر وجود ندارد و در صورت تنظیم با خطای زیر مواجه خواهیم شد:
در مطلب قبلی سعی کردیم تفاوتهای schema و user را در دیتابیس پستگرس و اوراکل تشریح کنیم. در این مطلب به اهدای مجوز در سطح اسکیما در این دو دیتابیس خواهیم پرداخت.
در دیتابیس پستگرس می توان به راحتی و با اجرای یک دستور مجوز دسترسی به تمامی جداول موجود در یک اسکیما را به کاربران اهدا کرد.مثال زیر را ببینید.
postgres=# \c postgres vahid
postgres=> select current_user;
vahid
postgres=> select * from myschema.tbl1;
ERROR: permission denied for schema myschema
خطای فوق عدم دسترسی کاربر vahid به جدول myschema.tbl1 را نشان می دهد. برای برطرف کردن این خطا، از طریق کاربر postgres که superuser هم هست به دیتابیس متصل شده و دستور زیر را اجرا می کنیم:
postgres=> \c postgres postgres
postgres=# grant usage on schema myschema to vahid;
GRANT
postgres=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA myschema TO vahid;
GRANT
همانطور که می دانید، user به منظور اتصال و مدیریت دیتابیس ایجاد می شود و schema هم مجموعه ای از objectها نظیر جدول، ایندکس، ویو و … تحت یک نام می باشد در این مطلب تفاوتهای user و schema را در دو دیتابیس پستگرس و اوراکل تشریح خواهیم کرد.
در دیتابیس اوراکل، با ایجاد user، به صورت خودکار schema هم ایجاد خواهد شد و به عبارتی دقیق تر، با ایجاد اولین object برای یک user، به آن user، اسکیما(schema) هم گفته می شود و دستور مجزایی برای ساخت schema وجود ندارد.
البته دستور CREATE SCHEMA که در اوراکل وجود دارد عملا schemaای را ایجاد نخواهد کرد و صرفا امکان ساخت چندین شی را از طریق یک دستور فراهم می سازد برای مثال با توجه به آنکه کاربر usef2 در دیتابیس موجود نیست، دستور زیر با خطا متوقف خواهد شد:
SQL> create schema authorization usef2
create table t1 (c1 number)
create table t2 (c2 number);
ORA-02421: missing or invalid schema authorization identifier
همانطور که در مطلب “Direct path vs Conventional insert“ بیان شد، زمانی که با اجرای دستور DMLای، تغییری را در جدولی ایجاد می کنیم، قبل از اجرای دستور commit، اوراکل بلاکهای جدول را به حافظه منتقل کرده و سپس اطلاعات جدید تایید نشده را در این بلاکها درج/حذف/اصلاح می کند(در حالت Conventional) همچنین شکل قبلی رکوردها در undo segment و یا rollback segment ثبت خواهد شد.
زمانی که دستور drop column را اجرا می کنیم، اوراکل باید تمامی بلاکهای جدول را به حافظه منتقل کرده و اطلاعات مربوط به ستون را از همه رکوردهای حاضر در بلاک حذف کند.
در کنار عملیات I/O و پردازش رکورد، جدول هم به صورت exclusive قفل خواهد شد و مضاف بر آن، حدف ستون منجر به ایجاد redo و undo هم می شود. در نتیجه حذف ستون از یک جدول حجیم می تواند کار بسیار پرهزینه و زمانبری باشد.مثال زیر را ببینید:
در سیستم عامل لینوکس به همراه دستوراتی که فضای مصرفی فایلها، دایرکتوریها و پارتیشنها را نمایش می دهند (نظیر df و du) می توان از سوییچ h برای نمایش خواناتر خروجی استفاده کرد که کلمه h مخفف عبارت Human-Readable می باشد.
مثال:
[oracle@host ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 543928992 169894132 346381740 33% /
tmpfs 178257920 351512 177906408 1% /dev/shm
/dev/sda1 499656 144960 318000 32% /boot
[oracle@host ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 519G 163G 331G 33% /
tmpfs 170G 344M 170G 1% /dev/shm
/dev/sda1 488M 142M 311M 32% /boot
در محیط دیتابیس هم توابعی وجود دارند که بتوان از طریق آنها حجم مصرفی segmentها و دیتابیس را به صورت خوانا نمایش داد.