1193 lines
51 KiB
Plaintext
1193 lines
51 KiB
Plaintext
|
||
PostgreSQL için Sıkça Sorulan Sorular (SSS)
|
||
|
||
Son güncelleme : 15 Kasım 2004 Pazartesi - 15:03:23
|
||
|
||
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
|
||
|
||
Çevirenler : Devrim Gündüz (devrim@tdmsoft.com)
|
||
Nicolai Tufar (ntufar@tdmsoft.com)
|
||
Volkan YAZICI (volkany@phreaker.net)
|
||
|
||
Bu belgenin en güncel hali,
|
||
http://www.PostgreSQL.org/docs/faqs/FAQ_turkish.html ve
|
||
http://www.gunduz.org/seminer/pg/FAQ_turkish.html adreslerinde
|
||
görülebilir.
|
||
|
||
Platforma özel sorularınız, http://www.PostgreSQL.org/docs/index.html
|
||
adresinde yanıtlanır.
|
||
_________________________________________________________________
|
||
|
||
Genel Sorular
|
||
|
||
1.1) PostgreSQL nedir? Nasıl okunur?
|
||
1.2) PostgreSQL'in hakları nedir?
|
||
1.3) PostgreSQL, hangi Unix platformlarında çalışır?
|
||
1.4) Hangi Unix olmayan uyarlamaları bulunmaktadır?
|
||
1.5) PostgreSQL'i nereden indirebilirim?
|
||
1.6) Desteği nereden alabilirim?
|
||
1.7) En son sürümü nedir?
|
||
1.8) Hangi belgelere ulaşabilirim?
|
||
1.9) Bilinen hatalar ya da eksik özelliklere nereden ulasabilirim?
|
||
1.10) Nasıl SQL öğrenebilirim?
|
||
1.11) PostgreSQL 2000 yılına uyumlu mudur?
|
||
1.12) Geliştirme takımına nasıl katılabilirim??
|
||
1.13) Bir hata raporunu nasıl gönderebilirim?
|
||
1.14) PostgreSQL, diğer VTYS(DBMS) lerle nasıl karşılaştırılabilir?
|
||
1.15) PostgreSQL'e maddi açıdan nasıl destek olabilirim?
|
||
|
||
Kullanıcı/istemci Soruları
|
||
|
||
2.1) PostgreSQL için ODBC sürücüleri var mı?
|
||
2.2) PostgreSQL'i web sayfalarında kullanabilmek için hangi araçlar
|
||
bulunmaktadır?
|
||
2.3) PostgreSQL'in grafik kullanıcı arabirimi var mıdır?
|
||
2.4) PostgreSQL ile iletişimi kurabilmek için hangi dilleri
|
||
kullanabilirim?
|
||
|
||
Yönetimsel Sorular
|
||
|
||
3.1) PostgreSQL'i /usr/local/pgsql dizininden başka dizinlere nasıl
|
||
kurabilirim?
|
||
3.2) Postmaster'ı başlattığımda Bad System Call ya da core dumped
|
||
mesajı alıyorum. Neden?
|
||
3.3) Postmaster'ı başlattığımda, IpcMemoryCreate hatası alıyorum.
|
||
Neden?
|
||
3.4) Postmaster'ı, başlattığımda, IpcSemaphoreCreate hatası alıyorum.
|
||
Neden?
|
||
3.5) Diğer bilgisayarların benim PostgreSQL veritabanı sunucuma
|
||
bağlantılarını nasıl kontrol edebilirim?
|
||
3.6) Veritabanı motorunu daha iyi başarım icin nasıl ayarlayabilirim?
|
||
3.7) Hangi hata ayıklama özellikleri bulunmaktadır?
|
||
3.8) Bağlanmaya çalışırken, neden "Sorry, too many clients" hatasını
|
||
alıyorum. Neden?
|
||
3.9) pgsql_tmpdizinin içindeki dosyalar nelerdir?
|
||
3.10) PostgreSQL sürümlerini yükseltmek için neden bir dump/reload
|
||
işlemi gerçekleştirmek zorundayım?
|
||
3.11) Nasıl bir donanım kullanmalıyım?br>
|
||
|
||
İşletimsel Sorular
|
||
|
||
4.1) Binary cursor ve normal cursor arasındaki fark nedır?
|
||
4.2) Sorgunun sadece ilk birkaç satırını nasıl SELECT edebilirim?
|
||
4.3) psql'in içinde gördügüm tabloların ya da diğer şeylerin listesini
|
||
nasıl alabilirim?
|
||
4.4) Bir tablodan bir kolonu nasıl kaldırabilirim?
|
||
4.5) Bir satır, tablo ve veritabanı için en fazla büyüklük nedir?
|
||
4.6) Tipik bir metin dosyasındaki veriyi saklamak için ne kadar disk
|
||
alanı gereklidir?
|
||
4.7) Veritabanında hangi tablo ya da index'lerin tanımlandığını nasıl
|
||
görebilirim?
|
||
4.8) Sorgularım cok yavaş, ya da index'lerimi kullanmıyorlar. Neden?
|
||
4.9) Query-optimizer'ın sorgularımı nasıl değerlendirdiğini, işleme
|
||
soktuğunu nasıl görebilirim?
|
||
4.10) R-tree index nedir?
|
||
4.11) Genetic Query Optimizer nedir?
|
||
4.12) Düzenli ifade (Regular Expression) aramalarını ve büyük/küçük
|
||
harfe duyarsız aramaları nasıl yapabilirim? Bu büyük/küçük harfe
|
||
duyarlı aramalar için index'i nasıl kullanabilirim?
|
||
4.13) Bir sorguda, bir alanın NULL olduğunu nasıl ortaya
|
||
çıkarabilirim?
|
||
4.14) Çesitli karakter tipleri arasındaki farklar nelerdir?
|
||
4.15.1) Nasıl serial/otomatik artan (auto-incrementing) bir alan
|
||
yaratabilirim?
|
||
4.15.2) Serial girişinin değerini nasıl alabilirim?
|
||
4.15.3) currval() ve nextval() diğer kullanıcılara sorun yaratmaz mı?
|
||
4.15.4) Neden sequence sayıların transaction işleminin iptalinden
|
||
sonra yeniden kullanılıyor? Neden sequence/SERIAL kolonumdaki
|
||
sayılarda atlamalar oluyor?
|
||
4.16) OID nedir? TID nedir?
|
||
4.17) PostgreSQL' de kullanılan bazı terimlerin anlamları nelerdir?
|
||
4.18) Neden "ERROR: Memory exhausted in AllocSetAlloc()" hatasını
|
||
alıyorum?
|
||
4.19) Hangi PostgreSQL sürümünü çalıstırdığımı nasıl görebilirim?
|
||
4.20) Neden large-object işlemlerim, "invalid large obj descriptor"
|
||
hatasını veriyor?
|
||
4.21) Şu andaki zamanı öntanımlı değer olarak kabul eden kolonu nasıl
|
||
yaratırım?
|
||
4.22) Neden IN kullanan subquery'lerim çok yavaş?
|
||
4.23) Outer join işlemini nasıl yapabilirim?
|
||
4.24) Aynı anda birden fazla veritabanında nasıl işlem yapabilirim?
|
||
4.25) Bir fonksiyondan nasıl çoklu satır ya da kolon döndürebilirim?
|
||
4.26) Neden Pl/PgSQL fonksiyonları içinden güvenli bir şekilde tablo
|
||
yaratma/kaldırma işlemlerini yapamıyoruz?
|
||
4.27) Hangi şifreleme seçenekleri bulunmaktadır?
|
||
|
||
PostgreSQL Özelliklerini Genişletmek
|
||
|
||
5.1) Kullanıcı-tanımlı bir fonksiyon yazdım. psql'de çalıştırdığım
|
||
zaman neden core dump ediyor?
|
||
5.2) PostgreSQL'e nasıl yeni veri tipleri/fonksiyonlar ekleyebilirim?
|
||
5.3) Bir tuple döndürmek için bir C fonksiyonunu nasıl yazarım?
|
||
5.4) Bir kaynak dosyasında değişiklik yaptım. Yeniden derlememe rağmen
|
||
değişiklik geçerli olmuyor. Neden?
|
||
_________________________________________________________________
|
||
|
||
Genel Sorular
|
||
|
||
1.1) PostgreSQL nedir? Nasıl okunur?
|
||
|
||
PostgreSQL, Post-Gres-Q-L. olarak okunur
|
||
|
||
PostgreSQL, yeni-nesil VTYS araştırma prototipi olan POSTGRES
|
||
veritabanı yönetim sisteminin geliştirilmesidir. POSTGRES'in zengin
|
||
veri tiplerini ve güçlü veri modelini tutarken, SQL'in geliştirilmiş
|
||
alt kümesi olan PostQuel dilini kullanır. PostgreSQL ücretsizdir ve
|
||
kaynak kodu açık dağıtılır.
|
||
|
||
PostgreSQL, PostgreSQL geliştirme listesine üye olan bir Internet
|
||
geliştirici takımı tarafından geliştirilir. Şu andaki koordinatör,
|
||
Marc G. Fournier (scrappy@PostgreSQL.org). (Bu takıma nasıl
|
||
katılacagınızı öğrenmek için 1.6 numaralı maddeyi okuyunuz.) Bu takım,
|
||
tüm PostgreSQL gelişiminden sorumludur.
|
||
|
||
PostgreSQL 1.01 sürümünün yazarları Andrew Yu ve Jolly Chen idi.
|
||
Bunların dışında bir kaç kisi de uyarlama, hata ayıklama ve kodun
|
||
geliştirilmesi için çalısmıştı. PostgreSQL'in türediği orijinal
|
||
Postgres kodu, lisans, lisansüstü ve akademisyenler tarafından,
|
||
Professor Michael Stonebraker (University of California, Berkeley)
|
||
koordinatörlügünde yazılmıştır.
|
||
|
||
Berkley'deki yazılımın adı Postgres idi. SQL uyumluluğu 1995'te
|
||
eklenince, adı Postgres 95 oldu. 1996 yılının sonlarında adı
|
||
PostgreSQL olarak değiştirildi.
|
||
|
||
1.2) PostgreSQL'in hakları nedir?
|
||
|
||
PostgreSQL Data Base Management System
|
||
|
||
Portions Copyright (c) 1996-2006, PostgreSQL Global Development Group
|
||
Portions Copyright (c) 1994-6 Regents of the University of California
|
||
|
||
Permission to use, copy, modify, and distribute this software and its
|
||
documentation for any purpose, without fee, and without a written
|
||
agreement is hereby granted, provided that the above copyright notice
|
||
and this paragraph and the following two paragraphs appear in all
|
||
copies.
|
||
|
||
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
|
||
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES,
|
||
INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND
|
||
ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN
|
||
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||
|
||
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
|
||
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
|
||
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
|
||
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
|
||
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
|
||
|
||
Üstteki metin klasik açık-kod lisansı olan BSD lisansıdır. Kaynak
|
||
kodun nasıl kullanılabileceğine dair sınırlamaları yoktur. Bu lisansı
|
||
seviyoruz. Değiştirme niyetimiz bulunmamaktadır.
|
||
|
||
1.3) PostgreSQL, hangi Unix platforlarında çalışır?
|
||
|
||
Genel olarak, modern bir Unix-uyumlu platform PostgreSQL'i
|
||
çalıştıracaktır. Ayrıntılı bilgi için kurulum belgelerine
|
||
bakabilirsiniz.
|
||
|
||
1.4) Hangi Unix olmayan uyarlamaları bulunmaktadır?
|
||
|
||
PostgreSQL 8.0 sürümü ile , PostgreSQL artık Win2000, WinXP ve Win2003
|
||
gibi Microsoft Windows NT tabanlı işletim sistemlerinde doğal olarak
|
||
çalışmaya başlamıştır. Paketlenmiş bir kurulum programı,
|
||
http://pgfoundry.org/projects/pginstaller. adresinden indirilebilir.
|
||
|
||
Ayrıca, http://forge.novell.com adresinde Novell Netware 6 portu
|
||
bulunmaktadır.
|
||
|
||
1.5) PostgreSQL'i nereden indirebilirim?
|
||
|
||
PostgreSQL için ana anonim ftp sitesi ftp://ftp.PostgreSQL.org/pub
|
||
adresidir. Yansılar için, ana web sayfamıza bakabilirsiniz.
|
||
|
||
1.6) Nereden destek alabilirim?
|
||
|
||
Ana e-posta listesi : pgsql-general@PostgreSQL.org. PostgreSQL
|
||
konusundaki tartışmalara açıktır. Üye olmak için, aşağıdaki satırları
|
||
e-postanızın body kısmına (konu kısmına değil) yazıp,
|
||
pgsql-general-request@PostgreSQL.org adresine gönderin:
|
||
subscribe
|
||
end
|
||
|
||
Aynı zamanda, bir digest listesi bulunmaktadır. Bu listeye üye olmak
|
||
için, pgsql-general-digest-request@PostgreSQL.org adresine, body
|
||
kısmında
|
||
subscribe
|
||
end
|
||
|
||
yazan bir e-posta atmanız yeterli olacaktır.
|
||
|
||
Digest postalar, ana liste 30k civarında e-postaya ulaştığında üyelere
|
||
gönderilmektedir.
|
||
|
||
Bug'lar için bir e-posta listesi bulunmaktadır. Bu listeye üye olmak
|
||
için, pgsql-bugs-request@PostgreSQL.org adresine, body kısmında
|
||
subscribe
|
||
end
|
||
|
||
yazan bir e-posta atmanız yeterli olacaktır.
|
||
|
||
Aynı zamanda, geliştiriciler için tartışma listesi bulunmaktadır. Bu
|
||
listeye üye olmak için, pgsql-hackers-request@PostgreSQL.org adresine,
|
||
body kısmında
|
||
subscribe
|
||
end
|
||
|
||
yazan bir e-posta atmanız yeterli olacaktır.
|
||
|
||
Bunun dışındaki e-posta listelerine ve PostgreSQL hakkında bilgiye,
|
||
PostgreSQL WWW ana sayfasından ulasabilirsiniz:
|
||
http://www.PostgreSQL.org
|
||
|
||
Aynı zamanda, EFNet üzerinde, #PostgreSQL adlı bir IRC kanalı
|
||
bulunmaktadır. Bunun için, irc -c '#PostgreSQL' "$USER"
|
||
irc.phoenix.net Unix komutunu kullanabilirsiniz.
|
||
|
||
Ticari destek veren firmaların listesine
|
||
|
||
http://www.postgresql.org/users-lounge/commercial-support.html
|
||
|
||
adresinden ulaşbilirsiniz.
|
||
|
||
1.7) En son sürüm nedir?
|
||
|
||
PostgreSQL'in son sürümü 7.4.6'dır.
|
||
|
||
Her 6-8 ayda ana sürüm çıkarılması planlanmaktadır.
|
||
|
||
1.8) Hangi belgelere ulaşabilirim?
|
||
|
||
Dağıtımın içinde, kitapçıklar, kitapçık sayfaları ve bazı küçük
|
||
örnekler verilmektedir. /doc dizinine bakınız. Ayrıca, bu el
|
||
kitapçıklarını online olarak http://www.PostgreSQL.org/docs/
|
||
adresinden inceleyebilirsiniz.
|
||
|
||
http://www.PostgreSQL.org/docs/awbook.html ve
|
||
http://www.commandprompt.com/ppbook adreslerinde PostgreSQL kitapları
|
||
bulunmaktadır. PostgreSQL kitablarının listesine,
|
||
http://www.ca.PostgreSQL.org/books/ adresinden ulaşaiblirsiniz.
|
||
Ayrıca, PostgreSQL konusundaki teknik makalelere de
|
||
http://techdocs.PostgreSQL.org/ adresinden ulaşabilirsiniz.
|
||
|
||
psql'in, \d ile baslayan veri tipler, operatorler, fonksiyonlar,
|
||
aggregate'ler, vb. ile ilgili güzel komutları vardır.
|
||
|
||
Web sitemiz daha fazla belgeyi içermektedir.
|
||
|
||
1.9) Bilinen hatalar ya da eksik özelliklere nereden ulaşabilirim?
|
||
|
||
PostgreSQL SQL-92 uyumluluğu içindedir, standartlardan fazla da
|
||
özellikleri bulunmaktadır. Bilinen hatalar, eksik özellikler ve
|
||
gelecek ile ilgili planlar için TODO listesine bakınız.
|
||
|
||
1.10) Nasıl SQL öğrenebilirim?
|
||
|
||
http:/www.PostgreSQL.org/docs/awbook.html adresindeki kitap SQL
|
||
ögretecektir. http://www.commandprompt.com/ppbook adresinde de bir
|
||
baska PostgreSQL kitabı bulunmaktadır.
|
||
|
||
http://www.intermedia.net/support/sql/sqltut.shtm,
|
||
http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM
|
||
http://sqlcourse.com ve http://sqlcourse2.com adreslerinde de güzel
|
||
belgeler bulunmaktadır.
|
||
|
||
Bir başkası da, http://members.tripod.com/er4ebus/sql/index.htm
|
||
adresinde bulunan "Teach Yourself SQL in 21 Days, Second Edition"
|
||
kitabıdır.
|
||
|
||
Bazı kullanıcılarımız da şu kitabı önermektedirler: "The Practical SQL
|
||
Handbook, Bowman, Judith S., et al.,Addison-Wesley". Bazıları ise "The
|
||
Complete Reference SQL, Groff et al., McGraw-Hill" kitabını
|
||
önermektedirler.
|
||
|
||
1.11) PostgreSQL 2000 yılına uyumlu mudur?
|
||
|
||
Evet.
|
||
|
||
1.12) Geliştirme takımına nasıl katılabilirim?
|
||
|
||
Öncelikle, en son kaynak kodunu indirin ve web sitemizdeki ya da
|
||
dağıtımın içindeki PostgreSQL Developer belgesini okuyun. Ardından,
|
||
pgsql-hackers ve pgsql-patches listelerine üye olun. Üçüncü olarak da,
|
||
pgsql-pacthes listesine yüksek kalitede yamalar gönderin.
|
||
|
||
PostgreSQL CVS arşivine erişim izni olan, 10 kadar geliştirici
|
||
bulunmaktadır. Hepsi defalarca, diğer kişilerin yaptığından çok daha
|
||
yüksek-kaliteli yamalar göndermişlerdir. Ayrıca biz de bu
|
||
geliştiricilerin ekledikleri yamaların yüksek kalitede olduğuna
|
||
güveniyoruz.
|
||
|
||
1.13) Bir hata raporunu nasıl gönderebilirim?
|
||
|
||
PostgreSQL BugTool sayfasına gidiniz. O sayfada bir bug bildirmek için
|
||
neleri yapmanız gerektiği anlatılmıştır.
|
||
|
||
Ayrıca, ftp://ftp.PostgreSQL.org/pub ftp adresimizde, yeni bir
|
||
PostgreSQL sürümü ya da yaması olup olmadığıni kontrol ediniz.
|
||
|
||
1.14) PostgreSQL, diger DBMS'lerle nasıl karşılastırılabilir?
|
||
|
||
Bir yazılımın gücünü ölçmek için çeşitli yollar vardır: Yazılımın
|
||
özellikleri, başarımı, güvenilirliği, desteği ve ücreti.
|
||
|
||
Özellikler:
|
||
|
||
PostgreSQL mevcut büyük ticari veritabanlarının, transaction,
|
||
subselect, trigger, view, foreign key referential integrity ve
|
||
sophisticated locking gibi (user-defined types), rules, inheritance ve
|
||
lock cakışmalarını düşürmek için multi-version uyumluluk özellikleri
|
||
bulunmaktadır.
|
||
|
||
Performans (Başarım):
|
||
|
||
PostgreSQL, diğer ticari ve açık kaynak kodlu veritabanlarıyla yakın
|
||
başarımı sağlar. Bazı açılardan daha hızlıdır, diğer açılardan da
|
||
yavaştır. MySQL ya da daha zayıf veritabanları ile
|
||
karşılaştırıldığında, INSERT/UPDATE işlemlerinde, transaction bazlı
|
||
çalıstığımız için daha yavaşız. MySQL, yukarıdaki "özellikler"
|
||
kısmında belirtilenlerden hiç birine sahip değildir. Biz, başarımımızı
|
||
her sürümde arttırsak da, esneklik ve gelişmiş özellikler için
|
||
yapılanmış durumdayız. PostgreSQL'i MySQL ile karşılaştıran şu web
|
||
sitesine bakabilirsiniz: http://openacs.org/why-not-mysql.html
|
||
|
||
Güvenilirlik:
|
||
|
||
DBMS'lerin güvenilir olması gerketiği, yoksa değerleri olmayacağını
|
||
düşünüyoruz. Çok iyi test edilmiş, dengeli çalısan minimum sayıda hata
|
||
içeren kod sunmaya çalışıyoruz. Her bir sürüm en az 1 aylık beta
|
||
testlerinden geçirilmektedir. Sürüm geçmişine bakarsanız, üretime
|
||
hazır, dengeli ve kararlı kodlar sunduğumuzu görebilirsiniz. Bu
|
||
alanda, diğer veritabanı yazılımlarına üstünlüğümüz olduğuna
|
||
inanmaktayız.
|
||
|
||
Destek:
|
||
|
||
E-posta listemiz, oluşan herhangi bir sorunu çözebilecek büyük sayıda
|
||
kullanıcı ve geliştirici grubunu içerir. Sorununuz için, en az bir
|
||
ticari veritabanı kadar rahat çözüm bulabilirsiniz. Gelistiricilere,
|
||
kullanıcı grubuna, belgelere ve kaynak koda direk olarak erişebilme,
|
||
PostgreSQL desteğini, diğer DBMS'lere göre daha önemli kılar.
|
||
Gereksinimi olanlara, ticari destek verilebilir. (Destek için 1.6
|
||
bölümüne bakınız.)
|
||
|
||
Fiyat:
|
||
|
||
Ticari ve ticari olmayan tüm kullanımlarınız için PostgreSQL
|
||
ücretsizdir. Kodumuzu, yukarıda belirtilen BSD-stili lisanstaki
|
||
sınırlamalar hariç, ürününüzün içine ekleyebilirsiniz.
|
||
|
||
1.15) PostgreSQL'e maddi açıdan nasıl destek olabilirim?
|
||
|
||
PostgreSQL, 1996 yılından beri 1. sınıf altyapıya sahiptir. Bunun
|
||
için, yıllar boyu çalışıp bu altyapıyı oluşturup yöneten Marc
|
||
Fournier'e teşekkürler.
|
||
|
||
Bir açık kaynak kodlu proje için, kaliteli altyapı çok önemlidir. Bu
|
||
altyapı, projenin kesilmesini önler ve projenin ilerlemesini
|
||
hızlandırır.
|
||
|
||
Tabii ki bu altyapı ucuz değildir. İşlerin yürümesi için çeşitli yılık
|
||
ve anlık harcamalarımız olmaktadır. Eğer siz ya da şirketinizin bu
|
||
çabamıza bağışta bulunabilecek parası varsa, lütfen
|
||
http://store.pgsql.com/ adresine gidiniz ve bağışta, hibede bulununuz.
|
||
|
||
Web sayfasının 'PostgreSQL Inc.' den bahsetmesine rağmen, "katkıda
|
||
bulunanlar" (contributors) maddesi sadece PostgreSQL projesini
|
||
desteklemek içindir ve belirli bir şirketin para kaynağı değildir.
|
||
isterseniz, bağlantı adresine bir çek gönderebilirsiniz.
|
||
_________________________________________________________________
|
||
|
||
Kullanıcı/İstemci Soruları
|
||
|
||
2.1) PostgreSQL icin ODBC sürücüleri var mı?
|
||
|
||
iki tane ODBC sürücüsü bulunmaktadır: PsqlODBC ve OpenLink ODBC.
|
||
|
||
PsqlODBC'i
|
||
http://gborg.postgresql.org/project/psqlodbc/projdisplay.php
|
||
adresinden indirebilirsiniz.
|
||
|
||
OpenLink ODBC http://www.openlinksw.com adresinden alınabilir.Bu
|
||
sürücü, kendi standart ODBC istemci yazılımı ile çalıstığından,
|
||
destekledikleri her platformda (Win, Mac, Unix, VMS) PostgreSQL ODBC
|
||
bulunmalidir.
|
||
|
||
Ücretsiz sürümü olmakla beraber, ticari kalitede destek almak
|
||
isteyenlere satmak isteyeceklerdir. Sorularınızı lütfen
|
||
postgres95@openlink.co.uk adresine gönderiniz.
|
||
|
||
2.2) PostgreSQL'i web sayfalarında kullanabilmek için hangi araçlar
|
||
bulunmaktadır?
|
||
|
||
http://www.webreview.com/ adresinde, arka planda veritabanı çalıstıran
|
||
Web sayfaları için giriş seviyesinde bilgi bulunmaktadır.
|
||
|
||
Web ile bütünleşme için, PHP () mükemmel bir arabirim sunar.
|
||
|
||
Karmaşık sorunlar için, çoğu kisi Perl arabirimini ve CGI.pm ya da
|
||
mod_perl kullanır.
|
||
|
||
2.3) PostgreSQL'in grafik kullanıcı arabirimi var mıdır?
|
||
|
||
Çeşitli grafik arabirimlerimiz bulunmaktadır. Bunların arasında,
|
||
PgAccess (http://www.pgaccess.org/), PgAdmin II
|
||
(http://www.pgadmin.org/, sadece Win32 için), RHDB Admin
|
||
(http://sources.redhat.com/rhdb/) ve Rekall
|
||
(http://www.thekompany.com/products/rekall/) bulunmaktadır. Ayrıca,
|
||
PostgreSQL için web tabanlı bir arabirim olan PHPPgAdmin
|
||
(http://phppgadmin.sourceforge.net/) bulunmaktadır.
|
||
|
||
Daha ayrıntılı liste için
|
||
http://techdocs.postgresql.org/guides/GUITools adresine
|
||
bakabilirsiniz.
|
||
|
||
2.4) PostgreSQL ile iletişimi kurabilmek için hangi dilleri kullanabilirim?
|
||
|
||
* C (libpq)
|
||
* Embedded C (ecpg)
|
||
* Java (jdbc)
|
||
* Python (PyGreSQL)
|
||
* TCL (libpgtcl)
|
||
|
||
Diğerleri için, http://gborg.postgresql.org adresindeki
|
||
Drivers/Interfaces bölümüne bakabilirsiniz.
|
||
_________________________________________________________________
|
||
|
||
Yönetimsel Sorular
|
||
|
||
3.1) PostgreSQL'i, /usr/local/pgsql dizininden başka dizinlere nasıl
|
||
kurabilirim?
|
||
|
||
configure betiğini çalıstırırken, --prefix seçeneğini veriniz.
|
||
|
||
3.2) postmaster'i baslattıgımda, a Bad System Call ya da core dumped mesajı
|
||
alıyorum. Neden?
|
||
|
||
Bunun birçok nedeni olabilir. Ancak ilk kontrol edilmesi gereken sey,
|
||
çekirdeginize System V uzantılarının kurulu olup olmadıgını kontrol
|
||
etmek olabilir. PostgreSQL shared memory ve semaphores için çekirdek
|
||
destegine gereksinim duyar.
|
||
|
||
3.3) postmaster'i başlattığımda, ıpcMemoryCreate hatası alıyorum. Neden?
|
||
|
||
Ya çekirdeğinizde shared memory desteğiniz düzgünce
|
||
yapılandırılmamıştır, ya da çekirdeğinizdeki mevcut shared memory
|
||
miktarını büyütmeniz gerekecektir. Gereksinim duyacağınız miktar,
|
||
mimarinize ve postmaster için ayarladıgınız tampon ile backend işlemi
|
||
sayısına bağlıdır. Tüm sistemler için, tamponlar ve işlemlerde
|
||
öntanımlı sayılarla, ~ 1MB kadar yere gereksinmeniz olacaktır.
|
||
PostgreSQL 7.3.2 Sistem Yöneticileri Rehberi'ne, shared memory ve
|
||
semaphorelar hakkındaki ayrıntılı bilgi için bakabilirsiniz.
|
||
|
||
3.4) postmaster'ı başlattığımda, ıpcSemaphoreCreate hatası alıyorum. Neden?
|
||
|
||
Eğer hata, "ıpcSemaphoreCreate: semget failed (No space left on
|
||
device)" ise, çekirdeğiniz yeterli semaphore ile yapılandırılmamış
|
||
demektir. Postgres, her bir potansiyel backend için bir semaphore
|
||
gereksinimi duyar. Geçici bir çözüm, postmasterı backend işlemleri
|
||
için daha az miktarda sınırla başlatmak olabilir. -N'i varsayılan
|
||
değer olan 32'den küçük bir değerle başlatınız. Daha kalıcı bir çözüm,
|
||
çekirdeğinizin SEMMNS ve SEMMNI parametrelerini yükseltmek olacaktır.
|
||
|
||
Çalışmayan semaphore'lar ağır veritabanı işlemlerinde çökme
|
||
yaratabilirler.
|
||
|
||
Eğer hata mesajınız başka bir şey ise, çekirdeğinizde semaphore
|
||
desteğini yapılandırmamış olabilirsiniz. Shared memory ve
|
||
semaphore'lar hakkındaki daha ayrıntılı bilgi için PostgreSQL 7.3.2
|
||
Sistem Yöneticileri Rehberi'ne bakabilirsiniz.
|
||
|
||
3.5) Diger bilgisayarların benim PostgreSQL veritabanı sunucuma
|
||
bağlantılarını nasıl kontrol edebilirim?
|
||
|
||
Ön tanımlı olarak, PostgreSQL sadece yerel makineden Unix domain
|
||
sockets kullanarak bağlanılmasına izin verir. Diger makineler,
|
||
postmaster'a -i etiketini geçirmezseniz ve $PGDATA/pg_hba.conf
|
||
dosyasını düzenleyerek host-based authentication'a olanak vermezseniz,
|
||
bağlantı yapamayacaklardır.
|
||
|
||
3.6) Veritabani motorunu daha iyi başarım için nasıl ayarlayabilirim?
|
||
|
||
Index'ler sorguları hızlandırabilir. EXPLAIN komutu, PostgreSQL'in
|
||
sorgunuzu nasıl yorumladığını ve hangi index'leri kullandığını
|
||
görmenize izin verir.
|
||
|
||
Eğer cok fazla INSERT işlemi yapıyorsanız, bunları büyük bir toplu
|
||
işlem dosyasıkullanıp COPY komutu ile veritabanına girmeyi deneyiniz.
|
||
Bu, tekil INSERT'lerden daha hızlıdır. İkinci olarak, BEGIN
|
||
WORK/COMMIT transaction bloğu içinde olmayan ifadeler kendi
|
||
transaction'larındaymış gibi düşünülür. Çoklu ifadeleri tek bir
|
||
transaction bloğu içinde yapabilirsiniz. Bu, transaction overhead'ini
|
||
düşürecektir. Tek bir transaction bloğu içinde birden çok ifadeyi
|
||
çalıştırmayı deneyebilirsiniz. Bu da aynı şekilde, transaction
|
||
overhead'ini düşürür.
|
||
|
||
Çeşitli ayarlama seçenekleri mevcuttur. fsync() işlemini, postmaster'ı
|
||
-o -F seçeneği ile başlatarak devre dışı bırakabilirsiniz. Bu işlem,
|
||
fsync()'lerin her transactiondan sonra diski flush etmesini
|
||
engelleyecektir.
|
||
|
||
Aynı zamanda, postmaster'i -B seçeneği ile başlatıp, backend işlemleri
|
||
tarafından kullanılan shared memory buffers sayılarını
|
||
arttırabilirsiniz. Eğer bu parametreyi çok yüksek tutarsanız,
|
||
çekirdeğinizin shared memory bölgesindeki limiti aşma olasılığınız
|
||
yüzünden postmaster başlayamayabilir. Her bir tampon (buffer) 8K'dır.
|
||
Öntanımlı sayı ise 64 tampondur.
|
||
|
||
Aynı şekilde, backend'in -S seçeneğini geçici sıralamalar için backend
|
||
süreçleri tarafından kullanılacak hafızayı arttırmak amacıyla
|
||
kullanabilirsiniz. -S seçeneği kilobayt cinsinden değer alır ve ön
|
||
tanımlı değeri 512'dir (512 K)
|
||
|
||
Tablolardaki veriyi bir index'e eşlemek amacıyla gruplama için CLUSTER
|
||
komutunu kullanabilirsiniz. Ayrıntılı bilgi için CLUSTER komutunun
|
||
yardım sayfasına bakabilirsiniz.
|
||
|
||
3.7) Hangi hata ayıklama özellikleri bulunmaktadır?
|
||
|
||
PostgreSQL, hata ayıklama amacıyla kullanılabilecek durum bilgisi
|
||
rapor eden çeşitli özeliklere sahiptir.
|
||
|
||
Öncelikle, configure betiğini --enable-cassert seçeneğiyle
|
||
çalıştırırsanız, bir çok assert() backend calışmasını gözlemler ve
|
||
beklenmeyen bir durumda programı durdurur.
|
||
|
||
Postmaster ve postgres çeşitli hata ayıklama seçeneklerine sahiptir.
|
||
Öncelikle, postmaster'ı başlattığınızda, standart çıktıyı ve hataları
|
||
bir log dosyasına yönlendirdiğinize emin olun:
|
||
cd /usr/local/pgsql
|
||
./bin/postmaster >server.log 2>&1 &
|
||
|
||
Bu işlem PostgreSQL ana dizinine server.log dosyası yerleştirecektir.
|
||
Bu dosya sunucunun yaşadığı sorunlar ya da hatalar hakkında yararlı
|
||
bilgiler içerir. -d seçeneği, hata ayıklama seviyesini belirten bir
|
||
rakam ile kullanılır. Yüksek hata ayıklama seviyelerinin büyük log
|
||
dosyaları oluşturacağını unutmayınız.
|
||
|
||
Eğer postmaster çalışmıyorsa, postgres backend'ini komut satırından
|
||
çalıştırabilir ve SQL ifadenizi direk olarak yazabilirsiniz. Bu sadece
|
||
hata ayıklama amacıyla önerilir. Burada, noktalı virgülün değil de
|
||
yeni bir satırın sorguyu sonlandırdığını unutmayınız. Eğer hata
|
||
ayıklama sembolleri ile derlediyseniz, ne olduğunu görmek için bir
|
||
hata ayıklayıcı kullanabilirsiniz. backend postmaster'dan
|
||
başlatılmadığından, eşdeğer bir ortamda çalışmamaktadır ve
|
||
locking/backend etkileşim sorunları artabilir.
|
||
|
||
Eğer postmaster çalışıyorsa, bir pencerede psql'i çalıştırın ve psql
|
||
tarafından kullanılan postgres sürecinin süreç numarasını (PID) bulun.
|
||
Postgres süreci ile ilişkilendirmek için bir hata ayıklarıcı kullanın.
|
||
Sorguları psql aracılığı ile çalıştırabilirsiniz. Eğer postgres
|
||
başlangıcında hata ayıklamak istiyorsanız, PGOPTIONS="-W n" seçeneğini
|
||
ayarlayabilir ve psql'i başlatabilirsiniz. Bu işlem, başlangıcın n
|
||
saniye kadar gecikmesini sağlayacaktır; böylece hata ayıklayıcıyı
|
||
sürece ilişkilendirdikten sonra başlangıç sürecinin devam etmesini
|
||
sağlayabilirsiniz.
|
||
|
||
postgres programı hata ayıklama ve başarım ölçümleri için -s, -A ve -t
|
||
seçeneklerine sahiptir.
|
||
|
||
3.8) Bağlanmaya çalışırken, neden "Sorry, too many clients" hatasını
|
||
alıyorum?
|
||
|
||
Postmaster'ın eşzamanlı olarak başlatabileceği backend süreçleri
|
||
sınırlarını arttırmanız gerekmektedir.
|
||
|
||
Ön tanımlı değer 32 süreçtir. Bunu, postmaster'ı uygun -N değeri ile
|
||
ya da postgresql.conf dosyasını düzenleyerek yeniden başlatmakla
|
||
arttırabilirsiniz.
|
||
|
||
Eğer -N değerini 32'den büyük yapacaksanız, aynı zamanda -B değerini
|
||
de değiştirmeniz gerektiğini unutmayın. -B, -N'nin en az 2 katı kadar
|
||
olmalıdır; daha iyi başarım için bu sayıyı daha da arttırmalısınız.
|
||
Yüksek sayıdaki backend süreçleri için, çeşitli çekirdek yapılandırma
|
||
parametrelerini arttırmanız gerekecektir. Yapılması gerekenler,
|
||
SHMMAX, SEMMNS, SEMMNI, NPROC, MAXUPRC ve açılabilecek dosyaların
|
||
maksimum sayısı olan NFILE ve NINODE değerlerini karıştırmaktır. Bunun
|
||
nedeni, PostgreSQL'in izin verilen backend süreçlerinin sayısı
|
||
üzerinde bir sınırı olmasıdır. Böylelikle sistem kaynaklarının dışına
|
||
çıkılmayacaktır.
|
||
|
||
PostgreSQL'in 6.5 sürümüne kadar, en fazla backend sayısı 64 idi ve
|
||
bunu değiştirmek için include/storage/sinvaladt.h dosyası içindeki
|
||
MaxBAckendid sabitini değiştirdek sonra yazılımı yeniden derlemek
|
||
gerekiyordu.
|
||
|
||
3.9) pgsql_tmp dizinin içindeki dosyalar nelerdir?
|
||
|
||
Sorgu çalıstırıcı (query executer) tarafından yaratılan geçici
|
||
dosyalardır. Örnegin, bir sıralama ORDER BY ile yapılacaksa ve
|
||
sıralama backend'in -s parametresinin izin verdiğinden daha fazla
|
||
alana gereksinim duyuyorsa, ekstra veriyi tutmak için geçici dosyalar
|
||
yaratılır.
|
||
|
||
Geçici dosyalar, eğer sıralama sırasında backend göçmezse otomatik
|
||
olarak silinecektir. Eğer çalışan durumda bir backend'iniz yoksa,
|
||
pg_tempNNN.NN dosyalarını silmeniz güvenlidir.
|
||
|
||
3.10) PostgreSQL sürümlerini yükseltmek için neden bir dump/reload işlemi
|
||
gerçekleştirmek zorundayım?
|
||
|
||
PostgreSQL takımı ara sürümlerde sadece küçük değişiklikler
|
||
yapmaktadır; bu yüzden 7.2 sürümünden 7.2.1'e yükseltmek dump/restore
|
||
işlemi gerekmemektedir. Ancak, esas sürümlerde (örnek: 7.2'den 7.3'e)
|
||
çoğunlukla sistem tablolarının ve veri dosyalarının iç yapısı
|
||
değiştirilir. Bu değişiklikler çoğunlukla karmaşıktır; dolayısıyla
|
||
veri dosyalarının geriye dönük uyumluluğu işlemlerini yapmıyoruz. Dump
|
||
işlemi, veriyi genel biçimde alacağından yeniden yükleme esnasında
|
||
veri, yeni iç biçime uygun şekilde yerleştirilecektir.
|
||
|
||
Disk biçiminin değişmediği sürümlerde, pg_upgrade betiği güncellemenin
|
||
bir dump/restore gerektirmeden yapılmasını sağlayacaktır. pg_upgrade
|
||
betiğinin o sürüm için bulunup bulunmadığını sürüm notları içinde
|
||
bulabilirsiniz.
|
||
|
||
3.11) Nasıl bir donanım kullanmalıyım?
|
||
|
||
PC donanımı tamamen uyumlu olduğu için, insanlar tüm PC donanımlarının
|
||
aynı kalitede olduğunu düşünürler. Oysa böyle değildir. ECC RAM, SCSI
|
||
ve kaliteli anakartlar daha ucuz donanımlara göre daha çok
|
||
güvenilirlerdir ve başarımları daha yüksektir. PostgreSQL hemen hemen
|
||
tüm donanımda çalışabilmektedir, ancak güvenilirlik ve başarım önemli
|
||
ise donanım seçeneklerini çok iyi araştırmak gereklidir. E-posta
|
||
listelerimi donanımlarla ilgili sorular ve de ticaret için
|
||
kullanılabilir.
|
||
_________________________________________________________________
|
||
|
||
İşletimsel Sorular
|
||
|
||
4.1) Binary cursor ve normal cursor arasındaki fark nedir?
|
||
|
||
DECLARE yardım sayfasına bakınız.
|
||
|
||
4.2) Sorgunun sadece ilk birkaç satırını nasıl SELECT edebilirim?
|
||
|
||
FETCH yardım sayfasına bakınız, ya da SELECT ... LIMIT ... kullanınız.
|
||
|
||
İlk birkaç satırı almak isteseniz bile, tüm sorgu değerlendirilmek
|
||
durumunda kalınabilir. ORDER BY içeren bir sorgu düşünün. Eğer ORDER
|
||
BY işe eşleşen bir index varsa, PostgreSQL istenen ilk birkaç satırı
|
||
işleyebilir, ya da tüm sorgu istenen satırlar üretilene kadar
|
||
işlenebilir.
|
||
|
||
4.3) psql'in içinde gördügüm tabloların ya da diğer şeylerin listesini
|
||
nasıl alabilirim?
|
||
|
||
pgsql/src/bin/psql/describe.c içindeki psql kaynak kodunu
|
||
okuyabilirsiniz. Bu kod, psql'in \ ile başlayan komutlarının çıktısını
|
||
olusturan SQL komutlarını içerir. Aynı zamanda, psql'i -E seçeneği ile
|
||
başlatıp, verdiğiniz komutları çalıştırmak için yaptığı sorguların
|
||
çıktılarını görebilirsiniz.
|
||
|
||
4.4) Bir tablodan bir kolonu nasıl kaldırabilirim?
|
||
|
||
Bu özellik (ALTER TABLE DROP COLUMN) 7.3 sürümü ile gelmiştir. Eski
|
||
sürümlerde aşağıdakileri uygulamalısınız:
|
||
BEGIN;
|
||
LOCK TABLE old_table;
|
||
SELECT ... -- select all columns but the one you want to remove
|
||
INTO TABLE new_table
|
||
FROM old_table;
|
||
DROP TABLE old_table;
|
||
ALTER TABLE new_table RENAME TO old_table;
|
||
COMMIT;
|
||
|
||
4.5) Bir satır, tablo ve veritabanı için en fazla büyüklük nedir?
|
||
|
||
Sınırlar:
|
||
|
||
Veritabanı için en fazla büyüklük nedir?
|
||
Sınırsız (32 TB'lık veritabanı bulunmaktadır)
|
||
Bir tablo için en fazla büyüklük nedir?
|
||
32 TB
|
||
Bir satır için en fazla büyüklük nedir?
|
||
1.6 TB
|
||
Bir alan için en fazla büyüklük nedir?
|
||
1 GB
|
||
Tabloda en fazla satır sayısı kaçtır?
|
||
Sınırsız
|
||
Bir tabloda olabilecek en fazla kolon sayısı kaçtır?
|
||
Kolon tiplerine bağlı olarak 250-1600
|
||
Bir tabloda olabilecek en fazla index sayısı kaçtır?
|
||
Sınırsız
|
||
|
||
Tabii ki bunlar aslında sınırsız degildir. Burada belirtilen sınırlar,
|
||
fiziksel sınırların haricindeki sınırlardır. Boş disk alanı,
|
||
hafıza/takas alanı na bağlı sınırlamalar vardır. Başarım, sınır
|
||
değerlere yaklaştıkça, ya da değerler çok büyük olduğunda düşebilir.
|
||
|
||
Bir tablo için büyüklük sınırı olan 32 TB, işletim sisteminin büyük
|
||
dosya desteği olup olmamasından bağımsızdır. Büyük tablolar, 1 GB'lik
|
||
dosyalarda saklandığı için, dosya sistemi sınırlarınin bir önemi
|
||
yoktur.
|
||
|
||
Tablo ve kolon sayısı büyüklükleri, ön tanımlı blok büyüklüğü 32k ya
|
||
çıkarılarak arttırılabilir.
|
||
|
||
4.6) Tipik bir metin dosyasındaki veriyi saklamak için ne kadar disk alanı
|
||
gereklidir?
|
||
|
||
Bir PostgreSQL veritabanı, veriyi "flat" metin dosyasında saklamak
|
||
için gereken alanın 5 kat fazla disk alanına gereksinim duyabilir.
|
||
|
||
Her satırında bir tamsayı ve metin (text) içeren, 100.000 satırlık bir
|
||
dosya düşünün. Her satırın ortalama 20 byte olduğunu farzedelim. Metin
|
||
dosyası 2.8 MB olacaktır. Bu veriyi tutan PostgreSQL veritabanı
|
||
yaklaşık 6.4 MB yer kaplayacaktır.
|
||
36 byte: Her bir satır başlığı (yaklaşık)
|
||
+ 24 byte: Bir tamsayı (int) alanı ve bir metin (text) alanı
|
||
+ 4 byte: Sayfada tuple a pointer
|
||
----------------------------------------
|
||
64 byte -> kayıt başına
|
||
|
||
PostgreSQL'de veri sayfası (data page) büyüklüğü 8192 byte (8k)dır,
|
||
dolayısıyla:
|
||
8192 byte -> page başına
|
||
------------------------- = Her bir veritabanı page'ı başına 128 satır (yaklaşık)
|
||
Satır başına 64 byte
|
||
|
||
100000 veri satırı
|
||
-------------------- = 782 veritabanı sayfası
|
||
128 satır
|
||
|
||
782 veritabanı sayfası * sayfa başına 8192 byte = 6,406,144 bytes (6.4
|
||
MB)
|
||
|
||
Index'ler çok fazla yere gereksinim duymazlar, ama index'lenmiş veriyi
|
||
tutacaklarından büyük olabilirler.
|
||
|
||
NULL değerler bitmapler içinde tutulur; dolayısıyla çok az yer
|
||
kaplarlar.
|
||
|
||
4.7) Veritabanında hangi tablo ya da index'lerin tanımlandığını nasıl
|
||
görebilirim?
|
||
|
||
psql, bu tür bilgileri göstermek için, \ ile başlayan bir çok komut
|
||
sunmaktadır. \? komutu ile bu komutları görebilirsiniz. Ayrıca,
|
||
bunları açıklayan ve pg_ ile başlayan çok sayıda sistem tablosu
|
||
bulunmaktadır. Aynı zamanda, psql -l ile tüm veritabanlarını
|
||
listeyelebirsiniz.
|
||
|
||
Ayrıca, pgsql/src/tutorial/syscat.source kodunu inceleyebilirsiniz. Bu
|
||
dosya, veritabanı sistem dosyalarından bilgiyi almak için gereksinim
|
||
duyulan bir çok SELECT'leri gösterir.
|
||
|
||
4.8) Sorgularım cok yavaş, ya da index'lerimi kullanmıyorlar. Neden?
|
||
|
||
Indexler her sorgu tarafından otomatik olarak kullanılmazlar. Indexler
|
||
eğer bir tablonun büyüklüğü minimum bir büyüklükten fazla ise ve sorgu
|
||
tablodaki satırların sadece küçük bir yüzdesini seçiyorsa kullanılır.
|
||
Bunun nedeni, index erişiminin neden olduğu raslansal disk erişimi nin
|
||
diskin ya da tablonun sıralı okunmasından daha yavas olabilmesidir.
|
||
|
||
Bir index'in kullanılıp kullanılmayacağını belirlemek için, PostgreSQL
|
||
tablo hakkındaki istatistiklere gereksinmesi vardır. Bu istatistikler,
|
||
VACUUM ANALYZE kullanılarak toplanırlar. Optimizer, istatistikleri
|
||
kullanarak, tabloda kaç satır olduğunu ve bilir ve indexin kullanılıp
|
||
kullanılmayacağına daha iyi karar verir. Istatistikler, aynı zamanda
|
||
en uygun join sırasını ve yöntemini belirlemekte çok önemlidir.
|
||
İstatistik toplanması, tablo içerikleri değiştikçe periyodik olarak
|
||
yapılmalıdır.
|
||
|
||
Indexler normalde ORDER BY sorguları ya da join işlemlerini
|
||
gerçekleştirmek için kullanılmazlar. Açık bir sıralamayı takip eden
|
||
sıralı bir arama (sequential scan), büyük bir tabloda index araması
|
||
yapmaktan genelde daha hızlıdır.
|
||
Ancak, ORDER BY ile birleşmiş LIMIT genellikle bir index
|
||
kullanacaktır; çünkü tablonun sadece belirli bir miktarı
|
||
döndürülecektir. Aslında, MAX() ve MIN() fonksiyonlarının index
|
||
kullanmamalarından dolayı, bu gibi değerleri ORDER BY ve LIMIT
|
||
kullanarak da almak olasıdır:
|
||
SELECT col
|
||
FROM tab
|
||
ORDER BY col [ DESC ]
|
||
LIMIT 1;
|
||
|
||
Eğer optimizer'ın sıralı arama yapmasının yanlış olduğuna
|
||
inanıyorsanız, SET enable_seqscan TO 'off' kullanın ve index kullanan
|
||
aramaların hala daha hızlı olup olmadığını görün.
|
||
|
||
LIKE ya da ~ gibi operatörler kullanıyorsanız, index'ler sadece
|
||
aşağıdaki koşullarda kullanılabilir:
|
||
* Arama dizininin başı, dizinin başı ile bağlanmalıdır. Yani,
|
||
+ LIKE sorguları % ile başlamamalıdır.
|
||
+ Düzenli ifade sorguları ^ işe başlamamalıdır.
|
||
* Arama metni bir karakter sınıfı ile başlayamaz. Örnek: [a-e]
|
||
* ILIKE ve ~* gibi büyük/küçük harfe duyarsız aramalar index'lerden
|
||
yararlanmazlar. Onun yerine, bölüm 4.12'de anlatılan fonksiyonel
|
||
index'leri kullanabilirsiniz.
|
||
* initdb sırasında öntanımlı C locale'i kullanılmalıdır.
|
||
|
||
4.9) query-optimizer'ın sorgularımı nasıl değerlendirdiğini, işleme
|
||
soktuğunu nasıl görebilirim?
|
||
|
||
EXPLAIN yardım sayfasına bakınız.
|
||
|
||
4.10) R-tree index nedir?
|
||
|
||
R-tree index, uzaysal (spatial) verileri indexlemek için kullanılır.
|
||
Bir hash index, dizi aramalarında (range search) kullanılamaz. B-tree
|
||
index dizi aramalarında sadece tek boyutlu çalışmaktadır. R-tree, çok
|
||
boyutlu veriyi destekler. Örneğin, eğer bir R-tree index point veri
|
||
tipi üzerinde inşa edililebilirse, sistem "select all points within a
|
||
bounding rectangle" gibi sorgulara daha verimli yanıtlar verecektir.
|
||
|
||
Orijinal R-tree tasarımını açıklayan belge:
|
||
|
||
Guttman, A. "R-trees: A Dynamic Index Structure for Spatial
|
||
Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of
|
||
Data, 45-57.
|
||
|
||
Bu belgeyi, Stonebraker'ın "Readings in Database Systems" kitabında
|
||
bulabilirsiniz.
|
||
|
||
Gömülü R-tree indexleri poligon ve boxları kullanabilir. Teorik
|
||
olarak, R-tree indexlerin özelliklerini genişletmek bir miktar çaba
|
||
gerektirir ve bunun nasıl yapılacağına dair bir belgemiz henüz
|
||
bulunmamaktadır.
|
||
|
||
4.11) Genetic Query Optimizer nedir?
|
||
|
||
GEQO modülü, Genetic Algorithm(GA) kullanılarak tablolar
|
||
birleştirildiğinde sorgu optimizasyonunu hızlandırır.
|
||
|
||
4.12) Düzenli ifade (Regular Expression) aramalarını ve büyük/küçük harfe
|
||
duyarsız aramaları nasıl yapabilirim? Bu büyük(küçük harfe duyarlı aramalar
|
||
için index'i nasıl kullanabilirim?
|
||
|
||
~ operatörü düzenli ifade eşleşmesi ve ~* büyük/küçük harfe duyarsız
|
||
düzenli ifade eşleşmesi yapar. Büyük/küçük harfe duyarlı olan LIKE'ın
|
||
büyük/küçük harfe duyarsız olan biçimi ILIKE'tır ve PostgreSQL 7.1
|
||
sürümü ile birlikte gelmiştir.
|
||
|
||
Büyük-küçük harfe duyarsız eşitlik karşılaştırmaları aşağıdaki gibi
|
||
ifade edilir:
|
||
SELECT *
|
||
FROM tab
|
||
WHERE lower(col) = 'abc'
|
||
|
||
Bu standart bir index yaratmayacaktır. Ancak eğer fonksiyonel bir
|
||
index yaratırsanız; o kullanılacaktır:
|
||
CREATE INDEX tabindex on tab (lower(col));
|
||
|
||
4.13) Bir sorguda, bir alanin "NULL" olduğunu nasıl ortaya çıkarabilirim?
|
||
|
||
Kolonu, IS NULL ve IS NOT NULL ile test edebilirsiniz.
|
||
|
||
4.14) Çesitli karakter tipleri arasındaki farklar nelerdir?
|
||
|
||
Veri Tipi İç Adı Not
|
||
--------------------------------------------------
|
||
VARCHAR(n) varchar boyut en büyük uzunluğu verir; sadece verilen kadar veri tutulur.
|
||
CHAR(n) bpchar belirtilen uzunluğa kadar sonuna boşluk eklenir.
|
||
TEXT text uzunlukta herhangi bir üst sınır yoktur.
|
||
BYTEA bytea variable-length byte array (null-byte safe)
|
||
"char" char bir karakter
|
||
|
||
İç adları (internal name) sistem kataloglarını ve bazı hata
|
||
mesajlarını incelerken göreceksiniz.
|
||
|
||
İlk dört veri tipi "varlena" tipidir (yani, diskteki ilk 4 bayt
|
||
uzunluktur; devamı da veridir.) Dolayısıyla, kullanılan gerçek alan,
|
||
belirtilen alandan biraz daha büyüktür. Ancak, bu veri tipleri,
|
||
sıkıştırılmaya tabi tutulabilir; dolayısıyla disk alanı beklenilenden
|
||
küçük olabilir. VARCHAR(n) büyüklüğü artabilen ama en büyük uzunluğu
|
||
sınırlı olan verileri saklamak için en uygun yöntemdir. TEXT, 1 GB
|
||
büyüklüğe kadar olan verileri tutmak için kullanılır.
|
||
|
||
CHAR(n), aynı uzunluktaki dizilerin saklanması için kullanımır.
|
||
CHAR(n) belirtilen uzunluğa kadar boşluk ile doldurur; ancak
|
||
VARCHAR(n) sadece verilen karakterleri saklar. BYTEA binary veri
|
||
saklamak içindir; ayrıca "NULL" bayt içeren değerleri de saklar.
|
||
Burada anlatılan üç veri tipi de benzer başarım karakteristiklere
|
||
sahiptir.
|
||
|
||
4.15.1) Nasıl serial/otomatik artan (auto-incrementing) bir alan
|
||
yaratabilirim?
|
||
|
||
PostgreSQL'de SERIAL veri tipi vardır. Bu veri tipi bir sequence ve
|
||
kolon üzerinde bir index yaratır.
|
||
|
||
Örnek, aşağıdaki sorgu:
|
||
CREATE TABLE person (
|
||
id SERIAL,
|
||
name TEXT
|
||
);
|
||
|
||
buna çevrilir:
|
||
CREATE SEQUENCE person_id_seq;
|
||
CREATE TABLE person (
|
||
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
|
||
name TEXT
|
||
);
|
||
CREATE UNIQUE INDEX person_id_key ON person ( id );
|
||
|
||
Sequenceler hakkında daha fazla bilgi için create_sequence yardım
|
||
sayfasına bakabilirsiniz. Her satırın OID alanını tekil bir sayı
|
||
olarak alabilirsiniz. Ancak, veritabanınızın dump'ını alıp yeniden
|
||
yüklerseniz, OID değerlerini koruyabilmek için pg_dump'ın -o
|
||
parametresini ya da "COPY WITH OIDS" seçeneğini kullanmanız
|
||
gerekecektir.
|
||
|
||
4.15.2) SERIAL girişinin degerini nasıl alabilirim?
|
||
|
||
Bir yaklaşım, sequence nesnesindeki SERIAL değerini, veriyi girmeden
|
||
önce nextval() ile alıp, aldığınız değeri kendinizin girmesidir.
|
||
4.15.1'deki örnek tabloyu kullanarak bir örnek verelim:
|
||
new_id = execute("SELECT nextval('person_id_seq')");
|
||
|
||
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
|
||
|
||
Diğer sorgular için new_id'de yeni değerin saklanması gerekir.
|
||
Otomatik olarak yaratılan SEQUENE nesnesinin adı, <tablo adı>_<serial
|
||
kolonu adı>_seq şeklinde olacaktır (< > işaretleri olmadan).
|
||
|
||
Alternatif olarak, atanmış SERIAL değerini, değer girildikten sonra
|
||
currval() fonksiyonu ile alabilirsiniz:
|
||
execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
|
||
new_id = execute("SELECT currval('person_id_seq')");
|
||
|
||
Son olarak, ön tanımlı değeri bulmak için INSERT ifadesinden dönen OID
|
||
değerini kullanabilirsiniz; ancak bu en az taşınabilir çözüm
|
||
olacaktır. Perl'de, Edmund Mergl'in DBD:Pg mödülü ile birlikte DBI
|
||
kullanarak, OID değeri $sth->execute() çalıştırıldıktan sonra
|
||
$sth->(pg_oid_status) ile alınabilir.
|
||
|
||
4.15.3) currval() ve nextval() diğer kullanıcılara sorun yaratmaz mı?
|
||
|
||
Hayır. curval(), tüm kullanıcılar değil, backend tarafından atanan
|
||
geçerli değeri döndürür.
|
||
|
||
4.15.4) Neden sequence sayıları transaction işleminin iptalinden sonra
|
||
yeniden kullanılıyor? Neden sequence/SERIAL kolonumdaki sayılarda atlamalar
|
||
oluyor?
|
||
|
||
Uyumluluğu arttırmak için, sequence değerleri çalışan transaction'lara
|
||
gerektiği şekilde aktarılır ve transaction bitene kadar o değer
|
||
kilitlenmez. Bu, iptal edilen transaction işlemleri nedeniyle
|
||
boşluklara neden olur.
|
||
|
||
4.16) OID nedir? TID nedir?
|
||
|
||
OIDler, tekil satır numaralarına PostgreSQL'in yanıtıdır.
|
||
PostgreSQL'de yaratılan her sayı, tekil bir OID alır. initdb işlemi
|
||
sırasında yaratılan tüm OID'ler 16384'ten küçüktür
|
||
(backend/access/transam.h). Kullanıcılar tarafından yaratılan tüm
|
||
OID'ler bu sayıya eşit ya da bu sayıdan büyüktür. Varsayılan durumda,
|
||
tüm bu OIDler sadece bir tablo ya da veritabanında değil, tüm
|
||
PostgreSQL kurulumunda tekildir.
|
||
|
||
PostgreSQL OIDleri, tablolar arasında satırları ilişkilendirmek için
|
||
kendi iç tablolarında kullanır. Bu OIDler belirli kullanıcı
|
||
satırlarını belirtmek için kullanabilir ve join işlemlerinde
|
||
kullanılır. OID değerlerini saklamak için OID kolon tipini kullanmanız
|
||
önerinir. Daha hızlı bir erişim için, OID alanında bir index
|
||
yaratabilirsiniz.
|
||
|
||
OID'ler yeni satırlara, tüm veritabanları tarafında kullanılan ortak
|
||
bir alandan atanırlar. Eğer OID'i başka bir değere eşitlemek
|
||
isterseniz ya da tablonun bir kopyasını orijinal OIDler ile çıkarmak
|
||
isterseniz, bu mümkündür:
|
||
CREATE TABLE new_table(old_oid oid, mycol int);
|
||
SELECT old_oid, mycol INTO new FROM old;
|
||
COPY new TO '/tmp/pgtable';
|
||
DELETE FROM new;
|
||
COPY new WITH OIDS FROM '/tmp/pgtable';
|
||
|
||
OIDler 4-bit tamsayı olarak saklanırlar ve 4 milyarda overflow
|
||
olacaktır. Kimse bu sayıya ulaştığına dair bir bilgi iletmedi ve bu
|
||
sınırı kimse bu sınıra ulaşmadan kaldıracağız.
|
||
|
||
TIDler, belirli fiziksel satırlar block ve offset değerleri ile
|
||
belirtmekte kullanılır. TIDler, satırlar değiştiğinde ya da yeniden
|
||
yüklendiğinde değişirler. Index girdileri tarafından fiziksel
|
||
satırları göstermek için kullanılırlar.
|
||
|
||
4.17) PostgreSQL'de kullanılan bazı terimlerin anlamları nelerdir?
|
||
|
||
Kaynak kodun bir kısmı ve eski belgeler, daha geniş kullanım alanı
|
||
olan terimleri kullanırlar. Bunların bazıları:
|
||
* table, relation, class
|
||
* row, record, tuple
|
||
* column, field, attribute
|
||
* retrieve, select
|
||
* replace, update
|
||
* append, insert
|
||
* OID, serial value
|
||
* portal, cursor
|
||
* range variable, table name, table alias
|
||
|
||
Genel veritabanı terimleri,
|
||
http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary
|
||
/glossary.html adresinde bulunabilir.
|
||
|
||
4.18) Neden "ERROR: Memory exhausted in AllocSetAlloc()" hatasını alıyorum?
|
||
|
||
Sisteminizde sanal belleğinizi tüketmiş olabilirsiniz, ya da
|
||
çekirdeğiniz belli kaynaklar icin düşük bir sınıra sahip olabilir.
|
||
postmaster'ı başlatmadan önce aşağıdakileri deneyebilirsiniz:
|
||
ulimit -d 262144
|
||
limit datasize 256m
|
||
|
||
Kabuğunuza bağlı olarak, bunlardan sadece biri olumlu sonuç
|
||
verecektir, ama bu işlem veri segment sınırınızı arttıracak, ve belki
|
||
de sorgunuzun tamamlanmasını sağlayacaktır. Bu komut, varolan işleme
|
||
(current process) ve komut çalıştırıldıktan sonraki tüm alt işlemlere
|
||
uygulanır. Eğer SQL istemcinizle, backend'in çok fazla veri döndürmesi
|
||
nedeniyle bir sorun yaşıyorsanız, bunu istemciyi başlatmadan önce
|
||
deneyiniz.
|
||
|
||
4.19) Hangi PostgreSQL sürümünü çalıştırdığımı nasıl görebilirim?
|
||
|
||
psql arabiriminde, select version(); yazınız.
|
||
|
||
4.20) Neden large-object işlemlerim, "invalid large obj descriptor"
|
||
hatasını veriyor?
|
||
|
||
Large object işlemlerinizin uçlarına, yani lo_open ... lo_close
|
||
komutlarının çevresine, BEGIN WORK ve COMMIT koymanız gerekmektedir;
|
||
|
||
Şu anda, PostgreSQL kuralları large objectleri transaction commit
|
||
edildiğinde kapatarak uygulamaktadır. Dolayısıyla handle ile yapılacak
|
||
ilk şey invalid large obj descriptor hatası ile
|
||
sonuçlanacaktır.Dolayısıyla çalışan kodunuz eğer transaction
|
||
kullanmazsanız hata mesajları üretecektir.
|
||
|
||
Eğer ODBC gibi bir istemci arabirimi kullanıyorsanız, auto-commit'i
|
||
kapatmanız gerekebilir.
|
||
|
||
4.21) Şu andaki zamanı öntanımlı değer olarak kabul eden How do I create a
|
||
column that will default to the current time?
|
||
|
||
Alttakini kullanabilirsiniz:
|
||
CURRENT_TIMESTAMP:
|
||
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
|
||
|
||
4.22) Neden IN kullanan subquery'lerim çok yavas?
|
||
|
||
7.4 sürümünden önce, subqueryler. Eğer subquery sadece birkaç satır ve
|
||
outer query bol sayıda satır döndürüyorsa, IN en hızlısıdır. Sorguları
|
||
hızlandırmak için IN yerine EXISTS kullanın:
|
||
SELECT *
|
||
FROM tab
|
||
WHERE col1 IN (SELECT col2 FROM TAB2)
|
||
|
||
sorgusunu, aşağıdaki ile değiştirin:
|
||
SELECT *
|
||
FROM tab
|
||
WHERE EXISTS (SELECT col2 FROM TAB2 WHERE col1 = col2)
|
||
|
||
Bu işlemin hızlı olması için, subcol'un indexlenmiş bir kolon olması
|
||
gerekmektedir.
|
||
|
||
7.4 sürümü ve sonrasında, IN aslında normal sorgularla aynı karmaşık
|
||
join tekniklerini kullanır ve EXISTS'e tercih edilir.
|
||
|
||
4.23) Outer join işlemini nasıl yapabilirim?
|
||
|
||
PostgreSQL outer joins islemlerini SQL standartlarını kullanarak
|
||
gerçekleştirmektedir. Aşağıda 2 örnek bulunmaktadır:
|
||
SELECT *
|
||
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
|
||
|
||
ya da
|
||
SELECT *
|
||
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
|
||
|
||
Bu özdeş sorgular t1.col' i t2.col'ye join ederler ve aynı zamanda
|
||
t1'deki unjoined satırları (t2'de eşlenmemiş olanlarla) döndürürler.
|
||
RIGHT JOIN t2'nin unjoined satırlarını ekleyecektir. Bir FULL join,
|
||
eşleşmiş bütün satırları ve t1 ile t2'den tüm bağlanmamış (unjoined)
|
||
satırları alır. OUTER sözcüğü seçimseldir ve LEFT, RIGHT ve FULL join
|
||
işlemlerinde olduğu kabul edilir. Sıradan join işlemleri INNER JOIN
|
||
olarak adlandırılır.
|
||
|
||
Önceki sürümlerde, OUTER JOINler UNION ve NOT IN kullanılarak simüle
|
||
edilebiliyordu. Örneğin, tab1 ve tab2'yi birleştirirken, aşağıdaki
|
||
sorgu iki tablonun dıştan bağlanmasını sağlar:
|
||
SELECT tab1.col1, tab2.col2
|
||
FROM tab1, tab2
|
||
WHERE tab1.col1 = tab2.col1
|
||
UNION ALL
|
||
SELECT tab1.col1, NULL
|
||
FROM tab1
|
||
WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
|
||
ORDER BY col1
|
||
|
||
4.24) Aynı andan birden fazla veritabanında nasıl işlem yapabilirim?
|
||
|
||
Mevcut veritabanınız dışındaki başka bir veritabanınızı sorgulamanızın
|
||
bir yolu bulunmamaktadır. Bunun nedeni, PostgreSQL'in veritabanına
|
||
özel sistem katalogları yüklemesidir. Bu nedenle, cross-database bir
|
||
sorgunun nasıl davranacağını kestirmek zordur.
|
||
|
||
contrib/dblink fonksiyon çağrılarını kullanarak cross-database
|
||
sorgulara izin verir. Tabii ki, bir istemci değişik veritabanlarına
|
||
aynı anda erişim sağlayabilir ve bilgiyi bu şekilde birleştirebilir.
|
||
|
||
4.25) Bir fonksiyondan nasıl çoklu satır ya da kolon döndürebilirim?
|
||
|
||
7.3 sürümünde, bir fonksiyondan kolaylıkla çoklu satır ya da sütun
|
||
döndürebilirsiniz.
|
||
(http://techdocs.postgresql.org/guides/SetReturningFunctions)
|
||
|
||
4.26) Neden Pl/PgSQL fonksiyonları içinden güvenli bir şekilde tablo
|
||
yaratma/kaldırma işlemlerini yapamıyoruz?
|
||
|
||
PL/PgSQL fonksiyon içerikleri cache'ler. Bunun istenmeyen bir tarafı,
|
||
eğer bir PL/PgSQL fonksiyonu geçici bir tabloya erişiyorsa ve bu tablo
|
||
ileride kaldırılıp yeniden oluşturulduktan sonra fonksiyon yeniden
|
||
çağrılırsa, fonksiyon çalışmayacaktır; çünkü cache'lenmiş fonksiyon
|
||
hala eski geçici tabloyu gösteriyor olacaktır. Çözüm, geçici tablo
|
||
erişimleri için PL/PgSQL'de EXECUTE kullanmaktır. Bu, sorgunun her
|
||
seferinde yeniden işlenmesini sağlayacaktır.
|
||
|
||
4.27) 4.28) Hangi şifreleme seçenekleri bulunmaktadır?
|
||
|
||
* contrib/pgcrypto SQL sorgularında kullanılabilmesi için şifreleme
|
||
fonksiyonları içermektedir.
|
||
* İstemciden sunucuya iletişimi şifrelemek için, sunucuda ssl
|
||
seçeneği postgresql.conf içinde açık olmalıdır. Ayrıca,pg_hba.conf
|
||
dosyası içinde host ya da hostssl kaydı mutlaka olmalıdır ve
|
||
istemci sslmode kapatılmamalıdır. (Aynı zamanda,PostgreSQL'in
|
||
doğal SSL bağlantıları dışında ssh ya da ssl gibi 3.parti
|
||
şifrelenmiş veri iletimi de mümkündür.)
|
||
* Veritabanı kullanıcı adı ve şifreleri 7.3 sürümü ile birlikte
|
||
otomatik olarak şifrelenirler. Önceki sürümlerde, postgresql.conf
|
||
içindeki PASSWORD_ENCRYPTION seçeneğini aktif hale getirmeniz
|
||
gerekmektedir.
|
||
* Sunucunun kendisini şifreli dosya sistemi üzerinde
|
||
çalıştırabilirsiniz.
|
||
_________________________________________________________________
|
||
|
||
PostgreSQL Özelliklerini Genişletmek
|
||
|
||
5.1) Kullanıcı-tanımlı bir fonksiyon yazdım. psql'de çalıştırdığım zaman
|
||
neden core dump ediyor?
|
||
|
||
Sorunun nedeni birden fazla şey olabilir. Kullanıcı-tanımlı
|
||
fonksiyonunuzu stand-alone bir programda çalıştırmayı deneyiniz.
|
||
|
||
5.2) PostgreSQL'e nasıl yeni tipler/fonksiyonlar ekleyebilirim?
|
||
|
||
Çalışmalarınızı pgsql-hackers e-posta listesine gönderiniz. Kodunuz
|
||
incelendikten sonra /contrib dizinine konacaktır.
|
||
|
||
5.3) Bir tuple dondürmek icin bir C fonksiyonunu nasil yazarım?
|
||
|
||
PostgreSQL 7.3 sürümü ile birlikte, C, PL/PgSQL ve SQL kullanılarak
|
||
tablo-döndüren fonksiyonlar tamamen desteklenmektedir. Ayrıntılı bilgi
|
||
için PostgreSQL 7.3.2 Kullanıcı Rehberi'ne bakabilrisiniz. Bir örneği
|
||
contrib/tablefunc içinde bulabilirsiniz.
|
||
|
||
5.4) Bir kaynak dosyasında değişiklik yaptım. Yeniden derlememe rağmen
|
||
değişiklik geçerli olmuyor. Neden?
|
||
|
||
Makefile'lar include dosyaları için tam bir bağımlılık içermezler.
|
||
Öncelikle make clean, ardından da baska bir make işlemi yapmanız
|
||
gerekir. GCC kullanıyorsanız, configure betiğinin --enable-depend
|
||
seçeneğini, derleyicinin bağımlılıkları otomatik olarak hesaplaması
|
||
için kullanabilirsiniz.
|