……….آموزش، مشاوره و پشتیبانی……….
مجوزهای 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
برای توقف و یا استارت کردن دیتابیس پستگرس از دستور 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
قصد داریم در این متن، به تفاوت هر کدام از این گزینه ها بپردازیم.
در زمان اجرای یک پرس و جوی زمانبر، ممکن است تغییراتی در جداول مرجع این پرس وجو اعمال شود در این صورت، سوالی مطرح می شود که آیا این پرس و جوی در حال اجرا، تغییرات جدید را هم در محاسباتش اعمال می کند یا خیر؟
پاسخ این سوال به نوع جداول و ویوهای مرجع پرس و جو بستگی دارد برای مثال، در زمان رجوع به dynamic performance viewها ممکن است تغییرات ایجاد شده در زمان اجرای پرس و جو لحاظ شود و نهایتا خروجی آن پرس و جو را تغییر دهد.
اما در زمان رجوع به جداولی که اطلاعات کاربران در آن ذخیره می شود، اوراکل با لحاظ کردن scn زمان اجرای پرس و جو(زمانی که پرس و جو شروع به اجرا می کند)، تغییرات جدید را در آن اعمال نخواهد کرد.
در صورتی که تغییرات جدید در محاسبات اعمال نشوند و اوراکل صرفا با کمک تصویر ثابتی که از اطلاعات جدول دارد، پرس و جو را اجرا کند، اصطلاحا مفهوم read consistency توسط اوراکل رعایت شده است.
گاهی بدلایل مختلف، مانند عدم فضای کافی یا عدم دسترسی مستقیم به سیستم عامل، امکان تهیه دامپ بر روی ماشین/سرور مبدا مهیا نمی باشد. در این مواقع datapump این امکان را فراهم نموده تا فایل دامپ را بر روی یک ماشین/سرور دیگر ایجاد کنیم یا اطلاعات را بدون ایجاد فایل دامپ، مستقیما بر روی بانک مقصد بارگذاری نماییم. برای این منظور از ارتباط database link بین دو بانک اطلاعاتی استفاده می شود.
اسکریپت زیر، تعداد log switchهایی که در هر ساعت در دیتابیس رخ داده است را نمایش می دهد البته این پرس و جو برای DBAها بسیار شناخته شده و پراستفاده می باشد.
قبلا در مقاله های جداگانه، مطالبی را در مورد قابلیتهای PDB relocation و PDB cloning ارائه کردیم در اوراکل 19c، انجام این عملیات از طریق دستور DBCA آن هم به صورت silent قابل انجام است که در این مقاله، به این قابلیت جدید خواهیم پرداخت.
زمانی که یک دستور dml ای اجرا می شود ، بانک اطلاعاتی داده ها را، قبل از آن که تغییری بر روی آنها اعمال شود، درundo segment ها که در فضای undo tablespace قرار دارند ذخیره می کند تا در صورت لزوم از آنها برای عملیات هایی مثل rollback کردن یک دستور dml ای و flashback در سطح جداول استفاده کند. به این داده ها ، داده های بازگشتی می گویند .
در متن پیش رو، به شیوه های جستجو در محتویات فایلها با استفاده از دستور grep می پردازیم. برای انجام این جستجو، ابتدا باید با بعضی از سوییچهای دستور grep که مرتبط با این موضوع هستند، آشنا باشیم.
از این tablespace برای نگهداری موقت داده های بانک اطلاعاتی جهت انجام یک سری عملیات استفاده می شود . برای مثال اوراکل در زمان مرتب سازی داده ها، ابتدا از فضای PGA که در ساختار RAM تشکیل شده است، استفاده می کند و در صورت نبود فضای کافی، به سراغ temporary tablespace خواهد رفت و از این قسمت به عنوان یک فضای کمکی برای PGA استفاده می کند.
جهت نصب ابتدا می بایست oracle database در سیستم مورد نظر نصب شده باشد شایان ذکر است نسخه فوق پایین تر از نسخه 11g نباشد.
این نسخه از Oracle GoldenGate نسخه های پایگاده داده ذیل را پشتیبانی می کند:
Oracle 11g – 11.2.0.4
Oracle 12c – 12.1.0.2+, 12.2.0.1+
Oracle 18c – 18.1.0 (Cloud), 18.3.0 (On-Premise)