none
(Sumber: milis SQL Server) Identity ID Overflow RRS feed

  • Pertanyaan

  • Dear rekan2,


    Ketika saya melakukan insert ke tabel ada error seperti ini:

    Msg 8115, Level 16, State 1, Line 1
    Arithmetic overflow error converting IDENTITY to data type int.
    Arithmetic overflow occurred.


    saya cek field ID (int, identity, PK) di database, ternyata sudah mencapai limit 2147483647
    saya sudah ganti menjadi bigint, tetapi andaikata terjadi hal ini, apa ada solusi yang lebih baik?
    Dalam pikiran saya ada 2 opsi:
    1. Reseed Identity jadi 1, tapi jadi ga unik lg, soalnya ID nya ulang dari 1
    2. Ubah cara generate ID menjadi manual, dengan formula yyMMdd digabung dgn n transaksi, misal 1207061 dst sampe ganti hari, misal sblm ganti hari ID nya 1207061000

    Cara ini mnrt saya kedepannya akan lebih efektif tetapi untuk diimplementasikan ke program, terlalu byk yang harus diubah (aplikasinya ud besar)
    Bagaimana mnrt rekan2?apa ada opsi yg lebih baik?
    Pertanyaan kedua, transaksi di database saat ini ud mencapai milyaran data, jika saya ingin pindahkan data histori tersebut ke database lain sehingga tidak memberatkan database utama, tetapi jika saya ingin melakukan searching data histori tersebut tetap bisa, bagaimana caranya?
    Database yang saya pakai SQL Server 2008 Standard Edition.
    Terima kasih.


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.36
    Moderator

Jawaban

  • 1. Tambahkan guid column. Jangan mengandalkan id primary auto generate saja

    Minimal pada table transaksi, ada 5 column,

    Id auto generate,guid,no rekening, transfer amount, transaction date

    Id digunakan untuk sort

    Guid untuk criteria where mengambil data satu row transaksi

    Transaction date untuk criteria tanggal berapa sampai berapa

    2.

    Untuk masalah limit bigint, gunakan partition view

    Ada banyak table transaksi per period

    Contoh: table transaksi jan , table transaksi feb ,dst

    Dan semua itu dibungkus dalam  transaksi view

    Isi view itu pasti union dari banyak table transaksi per bulan

    3.

    Ini adalah issue scalability horizontal

    Pada server operational hanya menyimpan satu atau tiga bulan terakhir saja

    Sisa nya dipindahkan ke server data warehouse

    Tujuannya simple, distribusi beban server sesuai kebutuhan penggunaan user

    Secara overall,

    Design database harus dirubah karena data semakin banyak

    Refactoring dan scalability adalah hal yg lazim dilakukan ketika data bisnis semakin banyak

    Telat tuning itu pasti salah. Premature optimize juga salah

    Refactoring harus pada waktu yg tepat

    Dijawab oleh: Edwin Bernadus


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.40
    Moderator

Semua Balasan

  • max valuenya bigint kira2 4 milyar x max valuenya int (angkanya mungkin salah nih).

    jadi kalo identity yg int sekarang overflow dalam 1 bulan pun not worth considering alternative solution kalo dah ganti bigint :D

    2. Biasanya dari aplikasinya dah dibedain, search utk 3 bulan data (misalnya) dibedain ama search yg lebih lama. Coba perhatiin contohnya di internet banking system. Historical data baiknya ga cuma beda database (dalam pengertiannya sql server), tapi juga beda server, jadi seberapa berat pun query utk historical datanya ga akan mengganggu OLTP.

    Dijawab oleh: Panji


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.37
    Moderator
  • Benar pak panji...untuk saat ini saya ganti jadi bigint tidak akan masalah dlm bbrp waktu ke depan, klo sy cek ke MSDN untuk bigint sampai 9223372036854775808

    tp andaikata mencapai angka tersebut, solusi berikutnya apa pak?

    Untuk internet banking, itu sy coba ibank BCA, maksimal yg bisa sy view 1 bulan ke belakang. Stlh sy tanya ke CS nya, data tsb sudah dibackup ke tape lain.

    Jika ingin lihat transaksi lebih dari 1 bulan ke belakang, disarankan print buku, tp itupun terbatas sampai 6bln kebelakang, sisanya jg sudah dibackup ke t4 lain.

    Perlu waktu untuk memprosesnya. Data transaksi BCA kan pastinya banyak, dlm sehari bisa jutaan, bagaimana mereka me-manage ID primary key-nya?

    sehingga tidak ada yg data yg ID nya dobel.

    Terima kasih.


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.39
    Moderator
  • 1. Tambahkan guid column. Jangan mengandalkan id primary auto generate saja

    Minimal pada table transaksi, ada 5 column,

    Id auto generate,guid,no rekening, transfer amount, transaction date

    Id digunakan untuk sort

    Guid untuk criteria where mengambil data satu row transaksi

    Transaction date untuk criteria tanggal berapa sampai berapa

    2.

    Untuk masalah limit bigint, gunakan partition view

    Ada banyak table transaksi per period

    Contoh: table transaksi jan , table transaksi feb ,dst

    Dan semua itu dibungkus dalam  transaksi view

    Isi view itu pasti union dari banyak table transaksi per bulan

    3.

    Ini adalah issue scalability horizontal

    Pada server operational hanya menyimpan satu atau tiga bulan terakhir saja

    Sisa nya dipindahkan ke server data warehouse

    Tujuannya simple, distribusi beban server sesuai kebutuhan penggunaan user

    Secara overall,

    Design database harus dirubah karena data semakin banyak

    Refactoring dan scalability adalah hal yg lazim dilakukan ketika data bisnis semakin banyak

    Telat tuning itu pasti salah. Premature optimize juga salah

    Refactoring harus pada waktu yg tepat

    Dijawab oleh: Edwin Bernadus


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.40
    Moderator
  • Mumpung udah dijawab, saya ga jawab lagi :D

    Btw Om Edwin (atau yg lain), nanya ya, bukan nguji:D

    1. Kalo pake GUID (dan yg sejenis) apa ga berat kalo tabelnya sering di-join (bandingin ama int/bigint key)
    2. Praktek ini lazim nggak? (kayaknya mestinya iya, soalnya seingat saya replikasinya SQL Server juga pake GUID)

    Dijawab oleh: Panji


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.41
    Moderator
  • 1.

    pada praktek nya table history transaksi memiliki karakteristik yang berbeda dengan table master.

    table id primary key jarang digunakan untuk join.

    join biasa nya menggunakan column lain , contoh account id

    contoh criteria misalkan :  where transaction date

    2.

    untuk join sedapat mungkin menggunakan int atau bigint.

    jangan gunakan string atau guid untuk join. lebih lambat.

    jadi guid digunakan hanya untuk mencari satu row transaksi history saja.

    misal untuk kasus tracing issue transaksi:

    misalkan ada customer complain soal suatu baris transaksi

    Q: transaksi saya ada yang suspect , ketika hari bla bla bla , jam bla bla bla

    A: oh , bisa kasih kita transaction GUID nya ? supaya lebih cepat tracing issue ini

    Q: no guid xxxx-xxxx-xxxx-xxxx

    A: ok, kita masukkan dalam  log ticket issue no xxxx.

    dst dst ...

    fungsi lain GUID juga digunakan untuk menyamakan ID beda module / database

    kalau sudah ngomong in enterprise architecture, SOA dkk... guid berguna banget.

    misal ada 2 module,

    internet banking dan core banking.

    join transaksi (biarpun jarang digunakan) , melalu column guid.

    karena primary id auto generate sulit disamakan angka nya.

    terutama apabila ada transaksi yang gagal di satu tempat , rollback , 

    angka id auto generate langsung berbeda

    cukup ribet , kalau harus di reset lagi.

    btw , sorry ini jadi sedikit OOT , malah ngomong in GUID 

    Dijawab oleh: Edwin Bernadus


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.42
    Moderator
  • terima kasih pak edwin, penjelasannya bermanfaat sekali

    tp jujur saya masih bingung, mohon pencerahannya

    "Secara overall,
    Design database harus dirubah karena data semakin banyak
    Refactoring dan scalability adalah hal yg lazim dilakukan ketika data bisnis semakin banyak"

    - jika data semakin banyak, perubahan design database yg dimaksud itu contohnya spt apa pak?

    - refactoring dan scalability ini maksudnya apa pak?


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.42
    Moderator
  • harus ada mindset dalam setiap programmer / admin , 

    bahwa desain itu tidak boleh kaku. 

    harus mengikuti keperluan bisnis perusahaan itu.

    dalam hal ini ,  DBA harus lebih flexible apabila ada perubahan schema / structure table.

    contoh kasus seperti ini :

    1. suatu company , misal suatu pabrik atau bank baru buka.

    pada saat itu  table masih simple. tidak ada feature tambahan apa pun.

    toh buat apa ? bisnis aja belum tentu jalan.

    2. 3 tahun kemudian , company berkembang , transaksi menjadi banyak

    muncul issue seperti bigint tidak dapat menampung lagi total history transaksi

    solusi : table transaksi harus dibelah berdasarkan periode bulan

    3. 2 tahun kemudian , company semakin besar lagi.

    ada kebutuhan report BI (business intelligence),

    server menjadi lambat karena ada beberapa report complex yang menghabiskan resource terlalu besar.

    solusi : server harus dibelah 2, server operation / transaction (OLTP) dan server report (OLAP)

    4. 1 tahun kemudian , ada kebutuhan server tidak boleh down.

    uptime 99.9%,

    solusi : tambah server lagi. mirroring. 

    kalau satu server mati , switch ke server lain

    5. 1 tahun kemudian , company semakin besar lagi.

    logging system saja bisa memakan resource server operation sampai 20%.

    solusi : buat server baru lagi. menggunakan noSQL. pindahkan fungsi log ke server baru

    dst dst dst ...

    ya mungkin kurang lebih begitu contoh cerita nya.

    istilah keren nya mungkin dibilang scalability atau refactoring.

    intinya sama saja sih , jangan kaku. berubah trus.

    Dijawab oleh: Edwin Bernadus


    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Kamis, 26 Juli 2012 07.43
    Moderator