The document discusses optimizing data access in databases. It describes how to find efficient access paths by minimizing logical reads and using indexes, partitioning, and statistics. SQL statements are categorized based on selectivity, with weak selectivity including full table, partition, and index scans, while strong selectivity uses rowid access, index access, and single table hash cluster access. Main causes of inefficient paths and solutions are presented.
The technology has almost written off MySQL as a database for new fancy NoSQL databases like MongoDB and Cassandra or even Hadoop for aggregation. But MySQL has a lot to offer in terms of 'ACID'ity, performance and simplicity. For many use-cases MySQL works well. In this week's ShareThis workshop we discuss different tips & techniques to improve performance and extend the lifetime of your MySQL deployment.
The technology has almost written off MySQL as a database for new fancy NoSQL databases like MongoDB and Cassandra or even Hadoop for aggregation. But MySQL has a lot to offer in terms of 'ACID'ity, performance and simplicity. For many use-cases MySQL works well. In this week's ShareThis workshop we discuss different tips & techniques to improve performance and extend the lifetime of your MySQL deployment.
ORACLE PERFORMANCE TUNNING
1 – 1: Introduction to Oracle tuning
- The top-down approach to tuning
- The history of Oracle tuning
- A review of the Oracle architecture
- The goals of Oracle tuning
- Overview of SQL tuning
- Oracle network bottlenecks
- Oracle RAM usage and bottlenecks
- Oracle CPU usage and bottlenecks
- Oracle disk I/O overview
- Monitoring server (sat, vmstat, top, glance)
- Movement toward server consolidation
1 – 2: Oracle disk I/O tuning
- History of DASD
- Understanding disk I/O
- Monitoring disk I/O (AWR, dba_hist_filestatxs)
- Sorted hash cluster tables
- Disk I/O waits
- Oracle data buffer internals (db_cache_size)
- Caching data blocks in the PGA (parallel full-table scans)
- Blocksize and I/O performance
1 – 3: Oracle CPU Tuning
- Finding your cpu_count
- Measuring CPU usage with vmstat
- Oracle CPU usage
- Using processor affinity
- _optimizer_cost_model=cpu
- Parallel query and CPU
Woo hoo!
18c Qualified expressions for collections and records
Whitelisting with the ACCESSIBLE_BY Clause
More PL/SQL-Only Data Types Cross PL/SQL-to-SQL Interface
Optimizing Function Execution in SQL
The UTL_CALL_STACK Package
Privileges/Access Management for Program Units
Static Expressions In Place of Literals
Marking elements for deprecation
PL/Scope now includes SQL statements in its analysis
View the companion webinar at: http://embt.co/1xcLFjJ
If you’ve ever wanted to code or understand more about PL/SQL code, this 2-part series is for you.
Join Oracle ACE Director, Dan Hotka and Solutions Consultant Director, Scott Walz as they present and demo the fundamentals of PL/SQL and much more.
Watch the webinar to learn about:
+ PL/SQL variable types and naming convention
+ How to code PL-SQL
+ When to use IF-THEN-ELSE or CASE
+ Profiling and debugging PL/SQL
Design and develop with performance in mind
Establish a tuning environment
Index wisely
Reduce parsing
Take advantage of Cost Based Optimizer
Avoid accidental table scans
Optimize necessary table scans
Optimize joins
Use array processing
Consider PL/SQL for “tricky” SQL
MemSQL 201: Advanced Tips and Tricks WebcastSingleStore
Topics discussed include differences between columnstore and rowstore engines, data ingestion, data sharding and query tuning, lastly memory and workload management.
Watch the replay at https://memsql.wistia.com/medias/4siccvlorm
Optimizing Query is very important to improve the performance of the database. Analyse query using query execution plan, create cluster index and non-cluster index and create indexed views
ORACLE PERFORMANCE TUNNING
1 – 1: Introduction to Oracle tuning
- The top-down approach to tuning
- The history of Oracle tuning
- A review of the Oracle architecture
- The goals of Oracle tuning
- Overview of SQL tuning
- Oracle network bottlenecks
- Oracle RAM usage and bottlenecks
- Oracle CPU usage and bottlenecks
- Oracle disk I/O overview
- Monitoring server (sat, vmstat, top, glance)
- Movement toward server consolidation
1 – 2: Oracle disk I/O tuning
- History of DASD
- Understanding disk I/O
- Monitoring disk I/O (AWR, dba_hist_filestatxs)
- Sorted hash cluster tables
- Disk I/O waits
- Oracle data buffer internals (db_cache_size)
- Caching data blocks in the PGA (parallel full-table scans)
- Blocksize and I/O performance
1 – 3: Oracle CPU Tuning
- Finding your cpu_count
- Measuring CPU usage with vmstat
- Oracle CPU usage
- Using processor affinity
- _optimizer_cost_model=cpu
- Parallel query and CPU
Woo hoo!
18c Qualified expressions for collections and records
Whitelisting with the ACCESSIBLE_BY Clause
More PL/SQL-Only Data Types Cross PL/SQL-to-SQL Interface
Optimizing Function Execution in SQL
The UTL_CALL_STACK Package
Privileges/Access Management for Program Units
Static Expressions In Place of Literals
Marking elements for deprecation
PL/Scope now includes SQL statements in its analysis
View the companion webinar at: http://embt.co/1xcLFjJ
If you’ve ever wanted to code or understand more about PL/SQL code, this 2-part series is for you.
Join Oracle ACE Director, Dan Hotka and Solutions Consultant Director, Scott Walz as they present and demo the fundamentals of PL/SQL and much more.
Watch the webinar to learn about:
+ PL/SQL variable types and naming convention
+ How to code PL-SQL
+ When to use IF-THEN-ELSE or CASE
+ Profiling and debugging PL/SQL
Design and develop with performance in mind
Establish a tuning environment
Index wisely
Reduce parsing
Take advantage of Cost Based Optimizer
Avoid accidental table scans
Optimize necessary table scans
Optimize joins
Use array processing
Consider PL/SQL for “tricky” SQL
MemSQL 201: Advanced Tips and Tricks WebcastSingleStore
Topics discussed include differences between columnstore and rowstore engines, data ingestion, data sharding and query tuning, lastly memory and workload management.
Watch the replay at https://memsql.wistia.com/medias/4siccvlorm
Optimizing Query is very important to improve the performance of the database. Analyse query using query execution plan, create cluster index and non-cluster index and create indexed views
Antes de migrar de 10g a 11g o 12c, tome en cuenta las siguientes consideraciones. No es tan sencillo como simplemente cambiar de motor de base de datos, se necesita hacer consideraciones a nivel del aplicativo.
Finding ways to make ETL loads faster is not always obvious. Moreover, there is a difference in how to tune OLAP vs OLTP databases. Some of the techniques learned through years of tuning EBS seem to make no effect on tuning a BI ETL. This presentation will discuss why this is the case, present some techniques on how to find the bottlenecks in your BI ETL jobs and some techniques to tune these slow SQL statements, improving the speed of nightly ETL jobs. Attendees will learn the steps to monitor ETLs, capture Problem SQL and gain knowledge to improve the overall ETL Performance.
Database Systems Design, Implementation, and ManagementOllieShoresna
Database Systems: Design,
Implementation, and
Management
Eighth Edition
Chapter 11
Database Performance Tuning and
Query Optimization
Database Systems, 8th Edition 2
Objectives
• In this chapter, you will learn:
– Basic database performance-tuning concepts
– How a DBMS processes SQL queries
– About the importance of indexes in query processing
– About the types of decisions the query optimizer has
to make
– Some common practices used to write efficient SQL
code
– How to formulate queries and tune the DBMS for
optimal performance
– Performance tuning in SQL Server 2005
Database Systems, 8th Edition 3
11.1 Database Performance-Tuning Concepts
• Goal of database performance is to execute
queries as fast as possible
• Database performance tuning
– Set of activities and procedures designed to
reduce response time of database system
• All factors must operate at optimum level with
minimal bottlenecks
• Good database performance starts with
good database design
Database Systems, 8th Edition 4
Database Systems, 8th Edition 5
Performance Tuning: Client and Server
• Client side
– Generate SQL query that returns correct answer
in least amount of time
• Using minimum amount of resources at server
– SQL performance tuning
• Server side
– DBMS environment configured to respond to
clients’ requests as fast as possible
• Optimum use of existing resources
– DBMS performance tuning
Database Systems, 8th Edition 6
DBMS Architecture
• All data in database are stored in data files
• Data files
– Automatically expand in predefined increments
known as extends
– Grouped in file groups or table spaces
• Table space or file group:
– Logical grouping of several data files that store
data with similar characteristics
Database Systems, 8th Edition 7
Basic DBMS architecture
Database Systems, 8th Edition 8
DBMS Architecture (continued)
• Data cache or buffer cache: shared, reserved
memory area
– Stores most recently accessed data blocks in RAM
• SQL cache or procedure cache: stores most
recently executed SQL statements
– Also PL/SQL procedures, including triggers and
functions
• DBMS retrieves data from permanent storage and
places it in RAM
Database Systems, 8th Edition 9
DBMS Architecture (continued)
• Input/output request: low-level data access
operation to/from computer devices, such as
memory, hard disks, videos, and printers
• Data cache is faster than data in data files
– DBMS does not wait for hard disk to retrieve data
• Majority of performance-tuning activities focus on
minimizing I/O operations
• Typical DBMS processes:
– Listener, User, Scheduler, Lock manager, Optimizer
Database Systems, 8th Edition 10
Database Statistics
• Measurements about database objects and available
resources
– Tables, Indexes, Number of processors used,
Processor speed, Temporary space available
• Make critical decisions about improving query
processing efficiency
• Can be gathered manually by ...
An AMIS Overview of Oracle database 12c (12.1)Marco Gralike
Presentation used by Lucas Jellema and Marco Gralike during the AMIS Oracle Database 12c Launch event on Monday the 15th of July 2013 (much thanks to Tom Kyte, Oracle, for being allowed to use some of his material)
M.
AMIS organiseerde op maandagavond 15 juli het seminar ‘Oracle database 12c revealed’. Deze avond bood AMIS Oracle professionals de eerste mogelijkheid om de vernieuwingen in Oracle database 12c in actie te zien! De AMIS specialisten die meer dan een jaar bèta testen hebben uitgevoerd lieten zien wat er nieuw is en hoe we dat de komende jaren gaan inzetten!
Deze presentatie is deze avond gegeven als een plenaire sessie!
Tired of seeing the loading spinner of doom while trying to analyze your big data on Tableau? Learn how Jethro accelerates your database so you can interactively analyze your big data on Tableau and gain the crucial insights that you need without losing your train of thought. Jethro enables you to be completely flexible with no need for partitions in order to speed up the data. This presentation will explain how indexing is a superior architecture for the BI use case when dealing with big data while compared to MPP architecture.
When it comes to user experience a snappy application beat a glamorous one. Nothing frustrates an end user more than a slow application. Did you know that any wait time greater than one second will break a user's concentration and cause them to feel frustration? How can we create applications to meet user expectations? This class will cover all things performance from design to delivery. We will go over application design, user interface guidelines, caching guidelines, code optimizations, and query optimizations.
Brad McGehee's presentation on "How to Interpret Query Execution Plans in SQL Server 2005/2008".
Presented to the San Francisco SQL Server User Group on March 11, 2009.
Show drafts
volume_up
Empowering the Data Analytics Ecosystem: A Laser Focus on Value
The data analytics ecosystem thrives when every component functions at its peak, unlocking the true potential of data. Here's a laser focus on key areas for an empowered ecosystem:
1. Democratize Access, Not Data:
Granular Access Controls: Provide users with self-service tools tailored to their specific needs, preventing data overload and misuse.
Data Catalogs: Implement robust data catalogs for easy discovery and understanding of available data sources.
2. Foster Collaboration with Clear Roles:
Data Mesh Architecture: Break down data silos by creating a distributed data ownership model with clear ownership and responsibilities.
Collaborative Workspaces: Utilize interactive platforms where data scientists, analysts, and domain experts can work seamlessly together.
3. Leverage Advanced Analytics Strategically:
AI-powered Automation: Automate repetitive tasks like data cleaning and feature engineering, freeing up data talent for higher-level analysis.
Right-Tool Selection: Strategically choose the most effective advanced analytics techniques (e.g., AI, ML) based on specific business problems.
4. Prioritize Data Quality with Automation:
Automated Data Validation: Implement automated data quality checks to identify and rectify errors at the source, minimizing downstream issues.
Data Lineage Tracking: Track the flow of data throughout the ecosystem, ensuring transparency and facilitating root cause analysis for errors.
5. Cultivate a Data-Driven Mindset:
Metrics-Driven Performance Management: Align KPIs and performance metrics with data-driven insights to ensure actionable decision making.
Data Storytelling Workshops: Equip stakeholders with the skills to translate complex data findings into compelling narratives that drive action.
Benefits of a Precise Ecosystem:
Sharpened Focus: Precise access and clear roles ensure everyone works with the most relevant data, maximizing efficiency.
Actionable Insights: Strategic analytics and automated quality checks lead to more reliable and actionable data insights.
Continuous Improvement: Data-driven performance management fosters a culture of learning and continuous improvement.
Sustainable Growth: Empowered by data, organizations can make informed decisions to drive sustainable growth and innovation.
By focusing on these precise actions, organizations can create an empowered data analytics ecosystem that delivers real value by driving data-driven decisions and maximizing the return on their data investment.
Adjusting primitives for graph : SHORT REPORT / NOTESSubhajit Sahu
Graph algorithms, like PageRank Compressed Sparse Row (CSR) is an adjacency-list based graph representation that is
Multiply with different modes (map)
1. Performance of sequential execution based vs OpenMP based vector multiply.
2. Comparing various launch configs for CUDA based vector multiply.
Sum with different storage types (reduce)
1. Performance of vector element sum using float vs bfloat16 as the storage type.
Sum with different modes (reduce)
1. Performance of sequential execution based vs OpenMP based vector element sum.
2. Performance of memcpy vs in-place based CUDA based vector element sum.
3. Comparing various launch configs for CUDA based vector element sum (memcpy).
4. Comparing various launch configs for CUDA based vector element sum (in-place).
Sum with in-place strategies of CUDA mode (reduce)
1. Comparing various launch configs for CUDA based vector element sum (in-place).
Explore our comprehensive data analysis project presentation on predicting product ad campaign performance. Learn how data-driven insights can optimize your marketing strategies and enhance campaign effectiveness. Perfect for professionals and students looking to understand the power of data analysis in advertising. for more details visit: https://bostoninstituteofanalytics.org/data-science-and-artificial-intelligence/
2. http://emrahmete.wordpress.com/about/
Marmara Üniversitesi - Bilgisayar Teknolojisi ve
Programlama
Yıldız Teknik Üniversitesi - Bilgisayar Mühendisliği
Turkcell Teknoloji - Yazılım Geliştirme Mühendisi
emrahmete.wordpress.com
TROUG – Kurucu Üye, Yönetim Kurulu Üyeliği
Emrah METE
Yahoo OracleTurk Grubu Moderatör
3. Agenda
- How to find efficient access path?
- Logical Reads
- Main Causes of Inefficient Access Paths and Solutions
- Selectivity
- SQL Statements with Weak Selectivity
- Full Table Scans
- Full Partition Scans
- Full Index Scans
- SQL Statements with Strong Selectivity
- Rowid Access
- Index Access
- Single Table Hash Cluster Access
4. How to find efficient access path?
- Resource Consumption
- Efficiency / Speed
- Resource Utilization
5. Logical Reads
• CPU bound operation, it reflects CPU
utilization very well.
• Logical reads might lead to physical reads.
• Logical Reads is an operation subject to
serialization.
• Logical Reads is readily available at athe SQL
statement and execution plan operation
levels.
6. Logical Reads
• 5 logical reads per returned row Good
• Between 10 and 15 logical reads per returned row Acceptable
• Between 15 and 20 logical reads per returned row Inefficient
8. Main Causes of Inefficient Access
Paths and Solutions
Causes
• No suitable access structures (for example,
indexes) are available.
• A suitable access structure is available, but
the syntax of the SQL statement does not
allow the query optimizer to use it.
• The table or the index, or both, is not
partitioned.
• Query optimizer makes wrong estimations
because of a lack of statistics
Solutions
• Minimize the number of logical reads.
• Add new access structers or change pysical
layout.
• Up to date table statistics.
• Selectivity
- Operations with weak (high) selectivity
- Operations with strong (low) selectivity
10. SQL Statements with Weak Selectivtiy
- Full Table Scans
- Full Partition Scans
- Full Index Scans
11. FULL TABLE SCANS
• It is possible to perform a full
table scan on all tables
• the database engine reads all
of the table’s blocks below the
high watermark sequentially
12. FULL TABLE SCANS
Total Rows: 10000
N2=19: 24 Rows
Case1: Case2:
- Alter Table Enable Row Movement
- Alter Table Shrink Space
16. SQL Statements with Strong
Selectivtiy
- Rowid Access
- Index Access
- Single Table Hash Cluster Access
17. ROWID ACCESS
- The most efficient way to access a row is to directly specify
its rowid in the where clause.
Data Object
Number
Relative File
Number
Block
Number
Row Number
ROWID FORMAT
10 Byte
ÖR:AAAR5cAAFAAAACfAAA
Efficiency or Speed: Efficient Access path her zaman en hızlı olan yöntemlerden biri olmayabilir. Parallel processing yeteneklerini kullanıp iyi response time’lar elde edebiliriz ancak, burada önemli olan nokta bu hızı ne kadar kaynak harcayarak yaptığımızıdır. Efficient access path, tüm sistem düşünüldüğünde SQL statementımızın daha az kaynak kullanarak (çünkü kaynaklar sınırlı), daha fazla ölçeklenebilir ve hızlı sonuçlar üretebilmesidir.
Resource Utilization: Dönen satır sayısı ile doğrudan ilgilidir. Basit bir mantıkla dönen satır sayısı az ise resource utilization az, dönen satır sayısı çok ise resource utilization çoktur. Ama burada ana metrik dönen 1 satır sonucunda ne kadar kaynak kullanıldığının kontrol edilmesidir.
Resource Consumption: İdeal hayatta, database engine tarafından yapılan kaynak tüketimi 4 başlık altında ölçümlenebilir. Bunlar CPU, Disk, Memory, Network ancak bu 4 parametre değerini toplayıp ölçümleyip değerlendirmek her bir SQL statementımız için oldukça zaman alıcı olabilir. Burada CPU’da bir satırın işlem görme süresi kullanılan CPU’ya bağımlı olarak değişkenlik gösterdiğin bu parametre üstünden yorum yapıp efficent access path’e gitmek oldukça zor olabilir (çünkü sistemden sisteme değişkenlik var CPU anlamında). Kullanılan memory miktarı döndürülen satır sayısına oranla değişebilir bazı durumlarda bilgiler doğrudan memory’den okunacağından dolayı network ve disk kaynakları her zaman kullanılmayadabilir. Uzun süren bir SQL’in hiç disk ve network kaynağı kullanmadan mütevazı bir memory kullanarak çalışıp sonuç döndürmesi aslında sıradan bir olaydır.
- Database engine’in işi bitirebilmesi için bir çok şey söyleyebilen, toplaması kolay bir parametre var oda logical Read sayısıdır.
Logical Reads: SQL çalıştığı esnada, buffer cache üzerinde bir block’a erişme olayına logical reads denir. SQL çalıştığı esnada buffer cache’den okunan blok sayısıda o sorgu için yapılan logical read sayısını gösterir.
Lojik okuma fiziksel okumalarada neden olabileceğinden dolayı, logical read sayısını düşürmek yapıacak I/O miktarınıda azaltmak anlamına gelebilir.
Logical Reads, overall Resource consumption bağlamında isabetli tahminlemeler yapmamıza olanak sağlayan bir parametre bu bağlamda Optimizayon un ilk bacağı olarak satır başına düşen yüksek lojik okuma sayılarına neden olan sorgulara odaklanabiliriz.
Logical Reads, overall Resource consumption bağlamında isabetli tahoracleminlemeler yapmamıza olanak sağlayan bir parametre bu bağlamda Optimizayon un ilk bacağı olarak satır başına düşen yüksek lojik okuma sayılarına neden olan sorgulara odaklanabiliriz.
ALTER SESSION SET STATISTICS_LEVEL = ALL;
select * from HR.COUNTRIES
SELECT plan_table_output
FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'RUNSTATS_LAST'));
Logical Reads: Access pathlerden hangileri daha az logical read yapar.
Selectivity doğru access path’i seçmek için çok önemlidir.
Selectivity’nin yüksek olduğu durumda tablo datasının büyük bir bölümünün getirileceği düşünülmelidir. Bu bağlamda Full Table Scan karşımıza ilk çıkan veri erişim yöntemidir. Bunun yanı sıra partitioning yaptığımız tablolarda full parttion scans gibi yöntemler ve sadece index okuma gibi yöntemlerde karşımıza çıkabilir.
Full table scans de logical read sayısı, blok sayısına eşit olmuş oluyor.
Selectivitynin çok zayıf olduğu durumlarda full table scan yapmak veriye erişmek için en etkili yöntem ancak selectivitynin düşmeye başladığı durumlarda bir çok blok gereksiz yere okunmaya başlar. Selectivitynin düşük olduğu durumda index kullanmakta efficient bir yöntem değildir. Bu tarz durumlarda logical reads sayısını düşürmek için seçilecek en etkin yöntem partitionlamadır. Optimizer gelen sorguya bakarak ilgili olmayan data barındıran partitionları okumayarak veri erişimini etkin kılar buna partition pruning denir.
Range Partition: Doğal olarak sıralı olan durumlarda örneğin belirli bir zaman aralığında öncesinde sonrasında..
List Part. : Distinct değer sayısı limitli olan durumlarda. Örneğin, cinsiyet, status,country,postal_codes gibi
Hash Part.:distinct kayıt sayısı çok fazla olan durumlarda kullanılması önerilir. Örneğin customer_id, sales_id ...
Sorgu geldiğinde optimizer where conditionına bakar ve partition keyin join conditionını inceleyerek ilgili datayı hangi partitionda arayacağını data dictionary ye bakarak karar verir ve ilgisi dışında olan partitionları budar (Partition pruning). Partition pruning yapılabilmesi için partition keylerin where koşulunda mutlak suretle olması beklenir aksi takdirde optimizer’ın datanın hangi partitionda aranacağını bilemez ve tüm partitionları tarayarak full table scan yapmak zorunda kalır.
Index ler yalnızca, kendileri üzerinden rowid listesi çıkarıp bu rowidlere karşılık kayıtları bulmak için tablolara gitmezler, indexler doğal olarak tablo üzerindeki bir yada birden çok kolonu key olarak aldıklarından ötürü üzerlerinde key olarak aldığı data yıda barındırmaktadırlar. Eğer gelen sorgunun dönüşü index key’in olduğu kolon ise rowid’yi alıp tabloya gitme gereksinimi kalmadan index keyi okuyup geriye sorgu sonucu olarak döndürebilmektedir. Bu sayede çok önemli bir veri erişim optimizasyonunu oracle kullanıcılarına sağlamaktadır.
Eğer index querry nin ihtiyaç duyduğu tüm datayı üzerinde barındırıyorsa, full table scan, full partition scan yerine full index scan yapılarak sorgu sonucu döndürülür. Full index scan, full table ve full partition scana göre çok daha efektif ve az lojik okuma yapan bir yöntemdir. Bunun nedenide index segmentlerinin tablo segmentlerinden daha ufak olmasıdır.
Eğer index buffer cache de yoksa, index disk üzerinden getirilmeye başlanır. İndexin büyük olduğu durumlarda okunacak blok sayısı artacağından dolayı daha fazla blok okuması yapılacak. Index full scan yöntemi blokları tek tek okuduğundan toplam blok sayısı, toplam okuma sayısına eşit olucak ve yöntem inefficient hale gelicek. Bu tarz durumlarda multiblock read tekniğini kulnnabilen index_fast_full scan yöntemini gerekli hinti verek kullanmak okuma sayısını düşürüp etkin bir yönteme sistemizmizi tekrar çevirebilir.
Selectivity nin 0 a yakın olduğu durumlar.
Selectivitynin düşük olduğu koşulda en etkili yöntemdir.
Belirli bir satıra erişmenin en etkin ve efektif yolu rowid ile erişmektir. Ancak bu etkin yolu kullanabilmek için ilk başta rowid yi çekip saklamak gerekmektedir. Daha sonra bir sonraki aynı satıra erişimizimizde doğrudan kullanabiliyoruz. Eğer bir satıra 2 kez erişiyorsak herhangi bir durum içerisinde burada ilk erişimimizi yaptığımızda rowid yide çekmek bir sonraki erişimimizi en etkin metod ile yapmamız anlamına gelecektir.
Selectivity nin strong olduğu durumlarda en sık kullanılan metodlardan biridir.
Clustering Factor Logical reads sayısını doğrudan etkileyen bir durum.-
Primary key üzerinden yapılmamalıdır. Distinct value değeri sınırlı olan kolonlar üzerinden yapılmalıdır. Cardinalty si düşük bir kolonum varsa ve tablomda çok büyükse, bitmap index btree index e göre daha performanslıdır. Ancak sorguda birden çok or lu and condition ının birleşmesi gerekliki bitmap indexin performansı artsın.
Bitmap index her zaman compress dir. B-tree index ancak istenilirse compress edilir.
Ana fikir tablo segmentlerini okumaktan kaçınmak çünkü index segmentleri tablo segmentlerinden daha küçüktür. Buda daha az lojik okuma yapmamız anlamına gelmektedir.
Eğer P.K üzerinden sıkça sorgu yaptığımız bir tablo durumu söz konusu ise ve bu tablodaki data karakteristiği indexli bir şekilde tutulmaya elverişli ise bu tabloyu IOT formatında tutmak performansı artırır.
Data hep clustered olarak saklandığından pk üzerinden yapılan range scan sorgulamaları çok efektif ve etkili oluyor.
Data primary key üzerinden organize edilmiş bir şekilde tutlduğu için olası bir order by işlemi çok etkin gerçekleşiyor.
Aynı key’e sahip olan tüm kayıtlar disk üzerinde beraber saklanıyorlar. Özellikle eşitlik içeren sorgularda index li erişime göre çok daha etkin ve efektif bir erişim sağlıyorlar.
Cluster key üzerinden bir fonksyon sonucunda hash key oluşturuyor ve bu hash key kayıtların disk üzerinde doğrudan nerede olduğunu gösteriyor.
Index gibi extra bir veri yapısına ihtiyacı olmadığından extradan fazla okuma yapmıyor.
Eğer cluster key üzerinden sık sorgulama sorgulama yapılıyorsa ve sizing doğru bir şekilde yapıldı ise performansı çok iyidir.
Cluster key primary key den farklı bir değer olabilir.
Hash collision dan kaçınmak için ve boşa diskten yer kaybetmemek için sizing doğru yapıılmalıdır.
Partitioning i desteklemez
Lob kolonları desteklemez.