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

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

(بیشتر…)

گلدن گیت – سرویس Manager

در این مطلب می خواهیم یکی از اجزای مهم گلدن گیت  به نام Manager  را شرح دهیم.

GoldenGate Manager  اولین سرویسی است که باید در پیکربندی replication تنظیم شود. این سرویس باید در هر دو سرور مبدأ (Source) و مقصد(Target) اجرا شود و اجرای آن برای پیکربندی و شروع سایر سرویسهای Goldengate ضروریست.

(بیشتر…)

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

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

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

(بیشتر…)

گلدن گیت – سرویس extract

جهت راه اندازی Oracle GoldenGate بایستی از اجزای آن شناخت کافی داشته باشید تا بتوانید به درک بهتر و عمیق تر از روند اجرای گلدن گیت در پایگاه  داده مبدا و مقصد برسید بنابراین دراین مطلب یکی از اجزای آن به نام Extract  را شرح می دهیم.

 نمونه هایی از اجزای GoldenGate به شرح ذیل می باشد:

  • Extract
  • Source Trail
  • Data Pump
  • TARGET TRAIL
  • Replicat
  • Manager

         

(بیشتر…)

اهدای مجوز 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

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

(بیشتر…)

مثالی در مورد مفهوم read consistency

در زمان اجرای یک پرس و جوی زمانبر، ممکن است تغییراتی در جداول مرجع این پرس وجو اعمال شود در این صورت، سوالی مطرح می شود که آیا این پرس و جوی در حال اجرا، تغییرات جدید را هم در محاسباتش اعمال می کند یا خیر؟

پاسخ این سوال به نوع جداول و ویوهای مرجع پرس و جو بستگی دارد برای مثال، در زمان رجوع به dynamic performance viewها ممکن است تغییرات ایجاد شده در زمان اجرای پرس و جو لحاظ شود و نهایتا خروجی آن پرس و جو را تغییر دهد.

اما در زمان رجوع به جداولی که اطلاعات کاربران در آن ذخیره می شود، اوراکل با لحاظ کردن scn زمان اجرای پرس و جو(زمانی که پرس و جو شروع به اجرا می کند)، تغییرات جدید را در آن اعمال نخواهد کرد.

در صورتی که تغییرات جدید در محاسبات اعمال نشوند و اوراکل صرفا با کمک تصویر ثابتی که از اطلاعات جدول دارد، پرس و جو را اجرا کند، اصطلاحا مفهوم read consistency توسط اوراکل رعایت شده است.

(بیشتر…)

استفاده از DataBaseLink در ابزارهای expdp/impdp

گاهی بدلایل مختلف، مانند عدم فضای کافی یا عدم دسترسی مستقیم به سیستم عامل، امکان تهیه دامپ بر روی ماشین/سرور مبدا مهیا نمی باشد. در این مواقع datapump این امکان را فراهم نموده تا فایل دامپ را بر روی یک ماشین/سرور دیگر ایجاد کنیم یا اطلاعات را بدون ایجاد فایل دامپ، مستقیما بر روی بانک مقصد بارگذاری نماییم. برای این منظور از ارتباط database link بین دو بانک اطلاعاتی استفاده می شود.

(بیشتر…)

اجرای PDB relocation و PDB cloning به صورت از راه دور با کمک DBCA

قبلا در مقاله های جداگانه، مطالبی را در مورد قابلیتهای PDB relocation و PDB cloning ارائه کردیم در اوراکل 19c، انجام این عملیات از طریق دستور DBCA آن هم به صورت silent قابل انجام است که در این مقاله، به این قابلیت جدید خواهیم پرداخت.

(بیشتر…)

آشنایی با مفاهیم داده های بازگشتی و undo tablespace

زمانی که یک دستور dml ای اجرا می شود ، بانک اطلاعاتی داده ها را، قبل از آن که تغییری بر روی آنها اعمال شود، درundo segment ها که در فضای undo tablespace قرار دارند ذخیره می کند تا در صورت لزوم از آنها برای عملیات هایی مثل rollback کردن یک دستور dml ای و flashback در سطح جداول استفاده کند. به این داده ها ، داده های بازگشتی می گویند .

(بیشتر…)