اخواني
استمرارا للفكرة التي طرحتها اطرح مشكلة اخري واجهتني في التقارير و اعتقد انها واجهت عددا منكم
و لا تزال تواجه البعض
و هي البطء في بعض التقارير التي تعتمد في الكويري علي فيوز تحتوي علي عدد كبير من الداتا و التابلز
انا ببساطة كان في تقارير شغالة علي فيوز بس كانت بطيئة جدا
و كان حلها اننا نعمل اندكس للكولمنز دي
بس الفيو ما ينفعش يتعمل عليها اندكس لانها فعليا مو موجودة
طيب ايه الحل
الحل اننا عملنا بدل الفيوز دي تابلز ديناميك فيها نفس داتا الفيو
و بنعملها دروب في الفورم قبل ماترن الريبورت يعني علي البتون اللي بيرن الريبورت
عن طريق الforms_ddl بلت ان
و بعد كدة نكريته تاني
مع عمل اندكس علي التابل ده
و بكدة قدرنا نخفض وقت التقرير مثلا من 25 او 30 دقيقة لاقل من دقيقة
تحياتي و اتمني ان اري مشاركتكم

مشكور على هذه الطريقة

فعلا طريقه جميله شكرا

ياليت تشرح لي الطريقة بالتفصيل بليز؟؟؟؟؟

السلام عليكم ورحمة الله و بركاته

اعتقد هناك طريقة افضل و هي استخدام Materialized views
حيث انك تستطيع ان تضع indx و بالتالي يكون هناك فرق في performance , واضح

شكرا

السلام عليكم ورحمة الله وبركاته

اخي الكريم hanon

ارجوا التكرم بوضع مثال عملي يوضح الطريقة المذكورة اعلاه


جزاك الله كل خير وبارك لك في اعمالك

الأخ jamal_rrkk

تطبيق هذه الطريقة مرتبط بوجود الفيو البطيئة و اعطاء مثال علي ذلك لن يكون ممكنا لي الأن حيث اني استخدمت هذه الطريقة منذ فترة كبيرة و نفس الظروف غير متوفرة الأن لي

و الطريقة مشروحة بالتفصيل يمكنك تطبيقها علي أي شئ تتطلب عملها و اذا واجهتك مشكلة يمكنني المساعدة فيها

و انصحك أيضا بتجربة الطريقة الخاصة بالMaterialized views
التي اشاؤر اليها الأخ المغربى في رده

بالتوفيق

بسم الله الرحمن الرحيم
السلام عليكم ورحمة الله وبركاته
السؤال يا أخي هل فكرة عمل الdrop والcreate للجدول ما بتعمل بطء وماهي عملية الdrop and create لو سمحت بشكل مختصر
والسلام عليكم ورحمة الله وبكراته

السلام عليكم

أخي ohmhs2006

هذا يعتمد علي حجم البيانات

و يمكن استعمال طرق أخري مثل عمل truncate أو delete للبيانات


حسب الأسرع

بالتوفيق

السلام عليكم
يمكنك إنشاء Temporary Table
لمرة واحدة، وفيها خاصية الحذف التلقائي بعد التخزين.

CREATE GLOBAL TEMPORARY TABLE my_temp_table (
 column1  NUMBER,
 column2  NUMBER
) ON COMMIT DELETE ROWS;

السلام عليكم ورحمة الله وبركاته

من خلال الرجوع للروابط التالية تبين ما يلي


http://www.psoug.org/reference/views.html

Primary Key - Type P

CREATE OR REPLACE VIEW <view_name>
(<column_name, column_name>
UNIQUE RELY DISABLE NOVALIDATE,
CONSTRAINT <constraint_name>
PRIMARY KEY (<column_name>) RELY DISABLE NOVALIDATE) AS
<select statement>;

Primary Key on a view
CREATE OR REPLACE VIEW person_pk_view 
(person_id, last_name 
UNIQUE RELY DISABLE NOVALIDATE,
CONSTRAINT pk_person_view
PRIMARY KEY (person_id) RELY DISABLE NOVALIDATE) AS
SELECT person_id, last_name FROM person;

SELECT constraint_name, constraint_type
FROM user_constraints
WHERE table_name = 'PERSON_PK_VIEW';

http://www.psoug.org/reference/materialized_views.html

Definitions
Complex Materialized View
Each row in the materialized view can not be mapped back to a single row in a source table.

Materialized View
A materialized view is a database object that contains the results of a query. The FROM clause of the query can name tables, views, and other materialized views. Collectively these objects are called master tables (a replication term) or detail tables (a data warehousing term). This reference uses "master tables" for consistency. The databases containing the master tables are called the master databases.

When you create a materialized view, Oracle Database creates one internal table and at least one index, and may create one view, all in the schema of the materialized view. Oracle Database uses these objects to maintain the materialized view data. You must have the privileges necessary to create these objects.

Materialized View Log
When DML changes are made to master table data, Oracle Database stores rows describing those changes in the materialized view log and then uses the materialized view log to refresh materialized views based on the master table. This process is called incremental or fast refresh. Without a materialized view log, Oracle Database must re-execute the materialized view query to refresh the materialized view. This process is called a complete refresh. Usually, a fast refresh takes less time than a complete refresh.

A materialized view log is located in the master database in the same schema as the master table. A master table can have only one materialized view log defined on it. Oracle Database can use this materialized view log to perform fast refreshes for all fast-refreshable materialized views based on the master table.

To fast refresh a materialized join view, you must create a materialized view log for each of the tables referenced by the materialized view.

http://www.psoug.org/reference/tables.html#gtt

Create Global Temporary Table
Global temporary tables have two major benefits:

1. Non-interference between private sets of data.

2. Ease of getting rid of 'scratch' data. In a heap table you either rollback, or delete it. But in a GTT, you can truncate explicitly, without affecting anyone else (or allow the implicit "truncate on commit / exit" effect to do 
the same thing).

3. Decreased redo generation as, by definition, they are non-logging.

However:

Mixing temporary tables (GTTs) with permanent tables usually causes some grief to the CBO. It has no information
about the number of rows in the GTT, and therefore guesses (badly).

Even if you analyze table .. or dbms_stats.gather_table_stats() you don't get stats on the temporary table.

Set the init parameter dynamic_sampling to at least 2 for GTTs to be sampled at run-time.

جزاكم الله كل خير وبارك لكم في اعمالكم