فیکس کردن plan بعضی از دستورات بعد از ارتقای دیتابیس

بعد از ارتقای دیتابیس به نسخه ای بالاتر، ممکن است زمان اجرای بعضی از پرس و جوها افزایش پیدا کند. این کندی می تواند به تغییراتی که در رفتار optimizer در هر نسخه از اوراکل ایجاد می شود، برگردد.

در جدول زیر اسامی تعدادی از قابلیتهایی که توسط optimizer در نسخه 11g و 12c قابل استفاده است را مشاهده می کنید:

در این متن به دنبال روشی هستیم که تغییر رفتار optimizer، در دو نسخه مختلف اوراکل را برای یک پرس و جوی مشخص نمایش داده و سپس با کمک قابلیت SQL Plan Management، پلن اجرایی ایجاد شده توسط optimizer، در یکی از این نسخه ها را برای پرس و جوی مورد نظر، فیکس کنیم.

(بیشتر…)

مخاطرات اهدای مجوز create any job به کاربران

با اهدای مجوز سیستمی create any job به یک کاربر، آن کاربر می تواند بدون اطلاع کاربران دیگر، برای آنها جاب ایجاد کند که در این صورت، کاربری که جاب را ایجاد می کند، creator و کاربری که جاب برای آن ایجاد می شود، owner نامیده می شود.

جاب ایجاد شده با مجوز owner اجرا می شود این مسئله به creator این امکان را می دهد تا با ایجاد جاب برای کاربران با سطح دسترسی بالا، مجوزی را برای خود اخذ کنند.

(بیشتر…)

بررسی تغییرات dbms_job در اوراکل 19c

تا قبل از اوراکل نسخه 10g، برای ایجاد جاب در محیط دیتابیس، از بسته dbms_job استفاده می شد در نسخه 10g بهبودی در این زمینه ایجاد شد و اوراکل با ارائه بسته dbms_scheduler، بسیاری از نقاط ضعف dbms_job را پوشش داد و عملا استفاده از این بسته را به حداقل رساند.

اما با این حال، کاربران می توانند کماکان از این بسته(dbms_job) برای تعریف جاب جدید و یا مدیریت جابهای قبلی(جابهای ایجاد شده در نسخه های قدیمی تر) استفاده کنند و حتی اوراکل هم برای زمانبندی بعضی از کارها، از همین بسته استفاده می کند.

(بیشتر…)

pin کردن object در shared pool

می دانیم که shared pool فرم پارس شده دستورات sql و pl/sql را در صورت دارا بودن فضای کافی در خود نگهداری می کند و نسخه قابل اجرای دستورات، در این قسمت از حافظه باقی خواهند ماند تا در صورت اجرای مکرر یک دستور، از کامپایل مجدد آن و یا به بیانی دقیق تر، از انجام عملیات hard pars جلوگیری شود.

فرض کنید به دلایلی چون عدم استفاده از bind variable در قسمتی از برنامه، فضای خالی ای در shared pool باقی نمانده است در این صورت، اوراکل فرمهای پارس شده را بر اساس الگوریتم LRU از حافظه خارج خواهد کرد این مسئله ممکن است سبب age out شدن objectهای سیستمی و یا applicationای شود که به کررات مورد دستیابی قرار می گیرند.

با در نظر داشتن این مسئله، قصد داریم به این سوال پاسخ دهیم که چگونه می توان این objectها را در shared pool سنجاق کرد تا الگوریتم LRU نتواند آنها را برای خروج از shared pool انتخاب کند.

(بیشتر…)

اوراکل 12c – جابجایی ترتیب قرارگیری ستونهای یک جدول

فرض کنید جدول mytbl را با دستور زیر ایجاد کرده ایم:

SQL> create table mytbl(id number,name varchar2(9),age number);

Table created

بعد از مدتی تصمیم گرفته ایم تا به این جدول، ستونی را با عنوان last_name اضافه کنیم:

SQL> ALTER TABLE mytbl ADD (last_name varchar2(9));

Table altered

ستون last_name  به لحاظ ترتیب قرار گیری بصورت پیش فرض، به عنوان آخرین ستون این جدول در انتهای لیست ستونها قرار می گیرد:

SQL> desc mytbl;

Name      Type        Nullable

——— ———– ——–

ID        NUMBER      Y                        

NAME      VARCHAR2(9) Y                        

AGE       NUMBER      Y                        

LAST_NAME VARCHAR2(9) Y 

قصد داریم ستونهای AGE و LAST_NAME را به لحاظ ترتیب منطقی قرارگیری در جدول با هم جابجا کنیم، برای این کار می توانیم از دستور ALTER TABLE .. MODIFY(COLUMN_NAME INVISIBLE) که در اوراکل 12c ارائه شد، استفاده کنیم. در قسمت زیر، نحوه انجام این کار را مشاهده می کنید:

SQL> ALTER TABLE mytbl MODIFY (LAST_NAME INVISIBLE,AGE INVISIBLE);

Table altered

SQL> ALTER TABLE mytbl MODIFY (LAST_NAME VISIBLE,AGE VISIBLE);

Table altered

SQL> desc mytbl;

Name      Type        Nullable Default Comments

——— ———– ——– ——- ——–

ID        NUMBER      Y                        

NAME      VARCHAR2(9) Y                        

LAST_NAME VARCHAR2(9) Y                        

AGE       NUMBER      Y    

(بیشتر…)

بهبودهای EZconnect در اوراکل 19c

زمانی که از پروتکل tcp/ip برای برقراری ارتباط با یک دیتابیس اوراکل استفاده می کنیم، اتصال به روش Easy Connect در مواردی می تواند جایگزین مناسبی برای فایل tnsnames.ora باشد. ساختار کلی Easy Connect تا قبل از اوراکل نسخه 19c، به صورت زیر می باشد:

host[:port][/service_name]

(بیشتر…)

اوراکل 12cR2- مروری بر دو بهبود ساده در دیتاپامپ

اوراکل 12c قابلیتهای را در زمینه Data Pump ارائه کرد که قبلا بعضی از آنها را مورد بررسی قرار داده ایم. در این متن به دو بهبود ساده اوراکل 12cR2 در این زمینه خواهیم پرداخت.

(بیشتر…)

بهبودی در جمع آوری خودکار آمار در اوراکل 19c

در محیطهای که نرخ تغییر داده نسبتا زیاد است، شاید استفاده از آمارهای بروز شده از طریق automated maintenance taskهای شبانه، چندان کارا نباشد با این نگاه، اوراکل در نسخه 19c، قابلیتهای جدیدی را در زمینه جمع آوری و بروزرسانی خودکار Statistic ارائه کرده که قبلا در مقاله ای یکی از این قابلیتها را که Real-time Statistic نام داشت، مورد بررسی قرار دادیم.

در این مقاله قصد داریم به یکی دیگر از این قابلیتها که High-frequency Optimizer Statistics Collection نام دارد، بپردازیم.

(بیشتر…)

اهدای مجوز insert و update در سطح ستون

مجوزهای insert و update را می توان در سطح ستونهای یک جدول به کاربران اهدا نمود.

دستور grant در مثال زیر، مجوز اجرای دستور update بر روی ستونهای name و last_name از جدول sys.mytbl را به کاربر usef اهدا می کند:

SQL> create table sys.mytbl(id number,name varchar2(9),last_name varchar2(9));

Table created

SQL> insert into sys.mytbl values(1,’vahid’,’usefzadeh’);

1 row inserted

SQL> commit;

Commit complete

SQL> grant update(name,last_name) on mytbl to usef;

Grant succeeded

(بیشتر…)

بررسی حالتهای shutdown در دیتابیس پستگرس

برای توقف و یا استارت کردن دیتابیس پستگرس از دستور pg_ctl استفاده می شود. فرمت کلی این دستور به صورت زیر می باشد:

pg_ctl start [-w] [-t seconds] [-s] [-D datadir] [-l filename] [-o options] [-p path] [-c]

pg_ctl stop [-W] [-t seconds] [-s] [-D datadir] [-m s[mart] | f[ast] | i[mmediate] ]

همانطور که در شکل کلی دستور pg_ctl قابل مشاهده است، استارت کردن دیتابیس پستگرس پییچدگی خاصی ندارد و صرفا می توان با اجرای دستور زیر، دیتابیس را استارت نمود:

[postgres@ol7 ~]$ pg_ctl -D /postgres/mydb  start

waiting for server to start….2019-09-04 01:55:24.914 EDT [22529] LOG:  listening on IPv6 address “::1”, port 5432

2019-09-04 01:55:24.914 EDT [22529] LOG:  listening on IPv4 address “127.0.0.1”, port 5432

2019-09-04 01:55:24.917 EDT [22529] LOG:  listening on Unix socket “/tmp/.s.PGSQL.5432”

2019-09-04 01:55:24.932 EDT [22530] LOG:  database system was shut down at 2019-09-04 01:55:21

2019-09-04 01:55:24.936 EDT [22529] LOG:  database system is ready to accept connections

 done

server started

اما برای متوقف کردن دیتابیس پستگرس، سه انتخاب وجود دارد:

smart|fast|immediate

قصد داریم در این متن، به تفاوت هر کدام از این گزینه ها بپردازیم.

(بیشتر…)