Pengalaman administrasi IBM DB2 Express-C saya ketika digunakan dengan 1C: Enterprise

Saya memiliki kesempatan untuk bekerja dengan IBM DB2. Baik pada 1C dan server pada Django menggunakan DBMS ini pada satu waktu, permintaan OLAP agak cepat diproses (meskipun, penyetelan indeks secara manual diperlukan, tentu saja, dari server web, tentu saja, sehingga responsnya dalam waktu 2 detik). Pada 2015, saya menyiapkan instruksi kecil ini untuk diri saya sendiri, agar tidak lupa. Dan sebagai tambahan pada resume, mungkin seseorang membaca di atas kertas, tahun-tahun kerja yang tersisa terbengkalai. Beberapa generalisasi pengalaman saya dengan DB2. Saya sedikit memperbaikinya dan menyarankan untuk membacanya di sini untuk memperluas wawasan saya. Mungkin seseorang akan tertarik. Saya harus segera mengatakan bahwa sejak itu saya tidak bekerja dengan DB2, semuanya telah dilupakan, tetapi saya masih ingat sesuatu. Selamat datang kritik dan klarifikasi, tetapi karena saya tidak lagi bekerja, mungkin bukan untuk saya, tetapi untuk orang lain, itu akan berguna.

Ada banyak instruksi di Internet bagaimana mengatur pekerjaan 1C: Perusahaan dengan DBMS IBM DB2. Sebagai permulaan, ini tidak buruk sama sekali, tetapi tidak cukup untuk digunakan dalam produksi. Saya sebelumnya merekomendasikan memulai dengan IBM DB2 dengan kursus pelatihan Big Data University DB101RU. Saya sendiri mengambil kursus ini, lulus ujian tahun 2012, saya pikir ini sangat berguna. Sangat disayangkan bahwa sumber daya tidak ada lagi. Di platform baru, saya tidak menemukan yang seperti itu. Dalam produksi, IBM DB2 memerlukan konfigurasi dan pemeliharaan tambahan, yang paling penting akan diuraikan secara singkat di sini. Kami sedang mempertimbangkan edisi gratis IBM DB2 Express-C untuk Windows versi 10.1fp2 dan 10.5fp4 (yang pertama didukung oleh 1C untuk bekerja dalam mode uji, yang kedua didukung secara resmi, sangat disayangkan bahwa versi yang lebih baru hanya dibayar). Masuk akal untuk menginstal 64-bit 10.5 di mana ada persyaratan tinggi untuk RAM (ukuran buffer untuk kecepatan) atau ukuran perekaman (EXTENDED_ROW_SZ = ENABLE) ketika menggunakan tipe komposit yang berisi string panjang ukuran tetap.

Hal pertama yang harus dilakukan adalah beralih ke menggunakan jurnal yang diarsipkan untuk membuat cadangan tanpa mengganggu operasi 1C: Enterprise, dan untuk dapat memulihkan database di setiap titik waktu (mengembalikan ke 10.1fp2 memiliki kekhasan tersendiri karena tidak dikoreksi bug dalam versi gratis - gerakan manual dari file log diperlukan). Tidak seperti MS SQL, pengarsipan log tidak dilakukan pada titik waktu yang telah ditentukan sebelumnya (dalam MS SQL tidak kuat, mungkin ada sesuatu yang lain), dan ketika file log mencapai ukuran tertentu yang telah ditentukan, tidak perlu membuat cadangan log sebelum operasi pemulihan, cukup nonaktifkan basisnya. Pengarsipan log dalam dua arah mudah dikonfigurasi, salah satunya ada di drive jaringan, misalnya. Selain itu, dalam kasus pemadaman jaringan pendek, peningkatan ruang yang ditempati oleh jurnal aktif tidak signifikan. Untuk log aktif, Anda harus menyediakan ruang kosong yang cukup untuk dapat memulihkan database pada waktu tertentu. Jika selama programer bekerja dengan basis 1C, pengembalian sering diperlukan pada berbagai titik dekat dalam waktu, satu cadangan sudah cukup untuk memulihkan, pilihan file log untuk pemulihan sangat sederhana. Pastikan untuk mengaktifkan database di awal instance, jika tidak kita akan mendapatkan sejumlah besar file log kecil dengan aktivasi implisit. Jelas, Anda harus mengatur waktu penyimpanan cadangan (bagi saya tampaknya Anda perlu menyimpan log setidaknya selama dua bulan) dan mengonfigurasi penghapusan otomatis. Basis dan cadangan (log) harus berada di disk fisik yang berbeda, dalam kasus ekstrem, Anda dapat membuat cadangan ke komputer lain di jaringan lokal.

Aktivasi basis juga diperlukan karena alasan lain. Untuk operasi normal, Anda harus menginstal windows online dan offline maintenance. Pada saat ini, markas harus aktif. Secara berkala, Anda harus melihat riwayat database untuk mencari tahu tindakan apa yang dilakukan selama jendela offline. Jendela pemeliharaan offline kemungkinan besar akan ditetapkan antara 22:00 - 0:00, karena tidak ada tugas pemeliharaan 1C yang berat saat ini. Mungkin untuk basis kecil, jendela yang tahan 1 jam sudah cukup.

Secara berkala, Anda perlu menjalankan pemeriksaan untuk kebutuhan reorganisasi dalam mode manual dan, setelah menganalisis keadaan tabel dan indeks, melakukan reorganisasi objek individu. Reorganisasi manual beberapa ribu tabel dan indeks bisa memakan waktu lama. Analisis mudah dipercepat dengan filter sederhana (pada .js, misalnya) menggunakan regexp.

AUTOCONFIGURE, tentu saja, harus dilakukan secara berkala, memperbaiki pengaturan individual secara manual, misalnya, mengatur ukuran file log Anda sendiri.

Setelah satu hari, adalah mungkin dan lebih sering untuk melakukan backup online dari database (tidak memerlukan shutdown dan kehadiran DBA), frekuensinya tergantung pada waktu pemulihan yang diperlukan, yang pada gilirannya tergantung pada jumlah file log yang diarsipkan setelah backup terakhir, yaitu beban pada database. Untuk basis data sedang, besar, dan penuh muatan, masuk akal untuk menggunakan berbagai jenis cadangan tambahan untuk mengurangi ruang yang ditempati oleh cadangan dan mengurangi waktu pemulihan dari cadangan. Setelah setiap cadangan dan sebelum memulihkan, periksa kesehatan cadangan. Waktu penyimpanan cadangan adalah atas kebijakan DBA, tetapi tidak kurang dari waktu penyimpanan log.

Setidaknya sebulan sekali, lakukan pemeriksaan kesehatan basis data offline dan online (dalam mode offline, bekerjalah dengan basis data ditangguhkan selama beberapa menit) dan, jika perlu, lakukan perbaikan (yang paling penting untuk "server" tanpa UPS). Lakukan pencadangan offline basis data setiap bulan, hanya pencadangan offline yang akan disimpan untuk waktu yang lama, karena ketika Anda mengubah versi DB2, pencadangan online tidak akan mungkin untuk digunakan. Jika "1C: Enterprise" bahkan tidak memungkinkan terjemahan jangka pendek dari database offline untuk verifikasi atau cadangan, dimungkinkan untuk melakukan tindakan yang ditunjukkan dalam salinan database yang diperluas. Basis data dipulihkan dari cadangan ke lokasi lain tanpa masalah, misalnya, ke disk lain di server lain. Perlu dicatat bahwa cadangan dan log yang diarsipkan dapat dikompres menggunakan alat DB2 (dalam hal ini, alat verifikasi cadangan tetap berfungsi dan alat verifikasi log yang diarsipkan tidak berfungsi).

Sebelum offline memeriksa database dan cadangan offline, Anda harus mengatur database dan tugas yang dijadwalkan untuk dikunci. Dalam keadaan darurat, Anda dapat melakukan dengan stabilisasi database, tetapi karena pengguna yang menjalankan 1C: Server perusahaan termasuk dalam grup SYSADM_GROUP, ini tidak akan membatalkan kemampuan untuk menghubungkan 1C ke database pada waktu yang salah dan, sebagai akibatnya, akan memerlukan kedua peluncuran pekerjaan.

Jika basis data tidak berfungsi dengan cepat, setelah memperbarui statistik, Anda harus mendapatkan rencana kueri paling parah, bereksperimen dengan indeks 1C dalam salinan basis data, memantau perubahan pada rencana kueri di IBM Data Studio (dalam hal ini, menggunakan gerhana dibenarkan, di lain hal itu cukup untuk dilakukan dengan antarmuka perintah) baris), atau gunakan rekomendasi dari DB2 Design Advisor dan, jika perlu, buat indeks secara manual di luar 1C. Pada saat yang sama, mulailah mengumpulkan informasi kinerja terperinci menggunakan alat DB2 (lebih dari selusin skrip SQL) dan menganalisis beban dengan monitor sistem. Untuk mengurangi beban pada sistem disk, database harus diinstal pada disk berkecepatan tinggi terpisah dengan ukuran yang cukup (kecuali, tentu saja, array disk server RAID 10 yang normal tersedia), dimungkinkan untuk menempatkan log aktif pada SSD bersama dengan OS. Mungkin, Anda juga perlu mengubah lokasi tempo 1C: Server perusahaan. Jika pembelian disk hanya direncanakan, untuk organisasi kecil diizinkan untuk sementara menggunakan disk fisik tunggal untuk database.

Tinjau db2diag.log setiap hari untuk kesalahan, serta hasil tindakan dengan database. Arsipkan setelah mencapai ukuran beberapa puluh megabyte. Far Manager dapat menjadi cara yang nyaman untuk melihat log (diasumsikan bahwa ada beberapa kesalahan dalam database), itu juga akan membantu jika Anda perlu memindahkan log arsip secara manual untuk memulihkan pada suatu titik waktu.

Salah satu keunggulan kompetitif IBM DB2, seperti yang terlihat bagi saya, dapat dianggap bahwa dalam kasus ketika untuk operasi normal dari MS SQL Server 64-bit 1C: Server perusahaan diperlukan, untuk IBM DB2 Anda dapat melakukannya dengan 32-bit.

UPD: Mungkin, dia tidak berhati-hati ketika memeriksa versi DB2 yang didukung oleh 1C: Enterprise sebelum diterbitkan. Dalam teks asli tahun 2015 ini, sekitar 10.5fp4 dikatakan: ketika digunakan dengan 1C: Enterprise, "belum ada kesalahan yang terdeteksi." Artinya, pada saat ini, Express-C yang baru, hanya 10.1 yang dimungkinkan (dengan fitur dan batasannya). Dari bayaran hari ini, hanya 11.1 yang didukung secara resmi. Ada kemungkinan bahwa seseorang akan memiliki cukup Developer-C dengan ukuran database hingga 100 GB. Saya tidak mengubah tautan ke dokumentasi - mudah untuk beralih ke sana.

UPD: Saya membaca kembali semuanya, mungkin harus jelas bagi seseorang yang berurusan dengan DB2, tetapi mungkin beberapa klarifikasi diperlukan bagi mereka yang baru bekerja dengan DBMS ini, misalnya

harus melihat riwayat pangkalan

harus membawa ke sini juga

melakukan pemeriksaan kesehatan database offline dan online

di sini , di sini dan di sini , tetapi dalam kasus terakhir mungkin sudah diperlukan
Dan ini dia

Analisis mudah dipercepat dengan filter sederhana (pada .js, misalnya) menggunakan regexp.

dapat menyebabkan kesulitan, saya tidak yakin apakah ada yang melakukan ini, bergantung pada otomatisasi, maksimum dibatasi untuk permintaan ini: db2 "SELECT substr(TABSCHEMA,1,20), substr(TABNAME,1,20) FROM SYSIBMADM.ADMINTABINFO WHERE REORG_PENDING = 'Y'" NamunSelanjutnya, analisis deskripsi dan mulai reorganisasi objek yang dipilih atau tingkatkan jendela pemeliharaan offline. Setelah beberapa iterasi, menjadi jelas objek mana yang tidak melakukan reorganisasi.
Saya harap saya tidak membingungkan apa pun, saya mengangkat arsip skrip lima tahun, mungkin resep. Saya tidak tahu apakah suplemen ini akan bermanfaat bagi siapa pun.

Tautan ke sumber daya / file yang disebutkan

Informasi dasar, kecuali yang diperoleh pada kursus yang tidak ada lagi, dapat ditemukan di sini (kemudian tautannya berbeda).

Banyak yang sudah dilupakan, tetapi tautan ke dokumen pdf “Praktik terbaik. Penyesuaian dan pemantauan kinerja sistem basis data ”ditemukan (tautannya sekarang baru, wiki lama tidak ada lagi sejak 2020-01-01, tetapi di sini semuanya sejauh ini tidak terlalu stabil).