……….آموزش، مشاوره و پشتیبانی……….
در دستورات SQL عملگرهای SET سطرهای چندین دستور SELECT را ترکیب کرده و ترتیب نمایش آنها را مشخص می کند. در این متن انواع روش های استفاده از عملگرهای SET توضیح داده می شود.
دستوراتی که در آنها از عملگر SET استفاده می شوند COMPOUND QUERY نام دارند. اولویت اجرای تمام روش های عملگر SET یکسان است. اگر در یک دستور SQL از چند عملگر SET استفاده شود ترتیب اجرای آنها از سمت چپ به راست خواهد بود مگر اینکه از علامت پرانتز استفاده شده باشد.
در مطلب “چرا Huge Page” در مورد مزایا و دلایل استفاده از Huge Page مطالبی را ارائه کردیم در این مطلب قصد داریم نکاتی را در مورد Huge Page برای دیتابیس اوراکل ارائه کنیم.
همانند دیتابیس پستگرس، دیتابیس اوراکل هم در صورت پیکربندی Huge Page در محیط سیستم عامل، به صورت خودکار و در زمان استارت شدن instance، برای فضای shared memory از Huge Page استفاده خواهد کرد.
اوراکل برای کنترل استفاده و یا عدم استفاده از Huge Page، پارامتر USE_LARGE_PAGES را ارائه کرده که در همین ابتدای متن، توضیحاتی را در مورد این پارامتر ارائه می کنیم.
ابزار AutoUpgrade ارتقا دیتابیس اوراکل به نسخه بالاتر را با مداخله کمتر DBA امکان پذیر می کند همچنین این ابزار، قابلیت ارتقا همزمان چندین دیتابیس را فراهم خواهد کرد(صرفا از طریق یک فایل config).
در این متن قصد داریم با استفاده از این ابزار، دیتابیسی را از نسخه 18c به نسخه 19c ارتقا دهیم.
تا قبل از اوراکل 12c، رفتار اوراکل در زمان جمع آوری آمار برای جداول از نوع (global temporary table(GTT تفاوتی با جداول معمولی نداشت و این مسئله می توانست در مواردی چالش برانگیز باشد.
در اوراکل 12c بهبودهایی در این زمینه حاصل شد که در ادامه دو مورد از این بهبودها را مشاهده می کنید.
دیتابیس اوراکل برای پیاده سازی مفاهیمی چون Data Concurrency و Read Consistency، مشخصات تراکنشها را در قسمتی از هدر بلاک ثبت می کند. این قسمت از هدر بلاک که به آن (Interested Transaction List(ITL هم گفته می شود، می تواند شامل تعدادی slot باشد.
تراکنشها برای تصاحب یک رکورد، باید slotای را در هدر بلاکی که رکورد در آن قرار دارد، در اختیار بگیرند و اطلاعاتی نظیر (transaction ID(XID و (undo block address(UBA و همچنین تعداد رکوردهایی که تراکنش در این بلاک قفل کرده را در این قسمت ثبت کنند البته هر slot صرفا به یک transaction تعلق دارد و هر transaction در هر بلاک، تنها می تواند یک slot را اشغال کند.
با انجام commit و rollback و متعاقب آن، پایان یافتن تراکنش، itl slot می تواند توسط تراکنش دیگری استفاده شود.
شرح خطا: خطای ORA-01034: ORACLE not available ممکن است در زمان اتصال به دیتابیس از طریق ابزارهایی چون Sqlplus، Sql Developer و … رخ دهد:
[oracle@stb ~]$ sqlplus “usef/p”
SQL*Plus: Release 18.0.0.0.0 – Production on Fri Oct 4 00:52:20 2019
Version 18.3.0.0.0
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory
زمانی که DBMS_SCHEDULER در اوراکل 10g ارائه شد، تنها سه نوع جاب PLSQL_BLOCK، STORED_PROCEDURE و EXECUTABLE را پشتیانی می کرد در اوراکل 11g هم تغییر قابل توجهی در این مسئله رخ نداد تا اینکه در نسخه 12c اوراکل job_typeهای جدیدی را به این مجموعه اضافه کرد تا تنظیم بعضی از جابها به شکل ساده تر و با وابستگی کمتری به محیط سیستم عامل قابل انجام باشد:
SHELL_SCRIPT – SQL_SCRIPT – BACKUP_SCRIPT
در این متن با هر کدام از این نوع جابها آشنا خواهیم شد.
زمانی را تصور کنید که ساختار جدول حجیمی را با کمک بسته DBMS_REDEFINITION تغییر داده ایم. بعد از اتمام عملیات redefinition، به این نتیجه رسیده ایم که تغییر انجام شده، سبب کندی در عملیاتی که بر روی این جدول انجام می شوند، شده است. قصد داریم جدول را به ساختار پارتشن نشده قبل برگردانیم، راهکار چیست؟
یکی از بهبودهایی که در نسخه 12c به بسته DBMS_REDEFINITION اضافه شد، قابلیت rollback کردن عملیات انجام شده می باشد این کار به کمک پارامتر enable_rollback از بسته DBMS_REDEFINITION قابل انجام است.
همانطور که می دانید در اوراکل 11g، برای هرگونه استفاده از بسته DBMS_REDEFINITION باید مراحلی را طی نمود و انجام عملیات در یک گام امکان پذیر نمی باشد.
در اوراکل نسخه 12c، پروسیجر جدیدی به نام REDEF_TABLE به بسته DBMS_REDEFINITION اضافه شده است که از طریق ان می توان عملیاتی نظیر جابجایی انلاین و تغییر tablespace جداول و همچنین تغییر نوع فشرده سازی جداول و ایندکسها را صرفا در یک مرحله انجام داد.
همانطور که می دانید، در زمان اجرای پروسیجر FINISH_REDEF_TABLE، باید برای مدت زمان کوتاهی جدول به صورت exclusive قفل شود تا اجرای پروسیجر با موفقیت خاتمه یابد در غیر این صورت، اجرای این پروسیجر تا اتمام تراکنشهایی دیگری که بر روی جدول در حال اجرا هستند، متوقف و در حالت انتطار باقی خواهد ماند: