mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-03 08:00:21 +08:00
f02a21b19b
Devrim GUNDUZ
898 lines
47 KiB
Plaintext
898 lines
47 KiB
Plaintext
PostgreSQL için Sıkça Sorulan Sorular (SSS)
|
||
|
||
Son güncelleme : 15 Kasım 2004 Pazartesi - 14:47:20
|
||
|
||
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-2002, 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,
|
||
o LIKE sorguları % ile başlamamalıdır.
|
||
o 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ı, __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) 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.
|
||
|