Kotak pasir
Valera 18 September 2013 jam 03:24 petang1C, pemulihan konfigurasi pangkalan maklumat menggunakan MS SQL
- Pelayan Microsoft SQL,
- Pentadbiran Pangkalan Data
Pada satu masa saya menghadapi masalah: apabila mengemas kini konfigurasi dari repositori, kegagalan berlaku dan 1C ditutup.
Seperti yang ternyata kemudian, storan konfigurasi telah dimusnahkan dan apabila mengemas kini konfigurasi, konfigurasi pangkalan data juga telah dipadamkan daripada storan. Ralat serupa berlaku sebelum ini semasa kemas kini dinamik keselamatan maklumat.
Kerana Masalah ini telah timbul lebih daripada sekali dan saya memutuskan untuk berkongsi pilihan rawatan.
Kali seterusnya anda memulakan configurator, ralat muncul: “Perhatian!!! Ralat berlaku semasa mengemas kini data selepas penstrukturan semula yang terakhir. Perlukah saya mengulangi kemas kini? Jika jawapannya ya, kami menerima mesej: "Operasi simpan konfigurasi yang tidak lengkap telah dikesan. Untuk terus bekerja, anda mesti menyelesaikan operasi" selepas itu aplikasi ditutup.
Apabila menganalisis masalah ini, beberapa penyelesaian kepada masalah ditemui, setiap penyelesaian berfungsi dalam kes yang berbeza.
Pilihan 1 (jika anda mempunyai sandaran SQL dengan salinan dengan konfigurasi yang sama):
Salinan keselamatan maklumat digunakan, dan permintaan berikut dilaksanakan:
GUNA GO DELETE FROM .. GO INSERT IN TO .. SELECT * FROM .. GO
Dalam kes ini, jadual di mana konfigurasi keselamatan maklumat disimpan diisi semula. Adalah dinasihatkan untuk menguji dan membetulkan keselamatan maklumat selepas operasi ini.
Pilihan 2 (jika tiada sandaran):
Pilihan ini telah dijadikan pilihan terakhir. Kerana konfigurasi sedang dalam pembangunan dan mereka terlupa tentang sandaran sedikit, bergantung pada storan.
Dalam pangkalan data, dua rekod dipadamkan daripada jadual "Config" dengan nilai dalam lajur "Nama Fail" - dbStruFinal dan komit
Pertanyaan berikut dilaksanakan:
GUNAKAN GO DELETE FROM . DI MANA FileName = "dbStruFinal" PERGI PADAM DARI . WHERE FileName = "commit" GO
Anehnya, asas itu menjadi hidup.
Tag: 1C Enterprise 8.2, SQL, pemulihan konfigurasi
Artikel ini tidak tertakluk kepada ulasan, kerana pengarangnya belum lagi menjadi ahli komuniti sepenuhnya. Anda akan dapat menghubungi pengarang hanya selepas dia menerima
prasejarah.
Dua hari lalu kami membuat peralihan daripada 8.1 kepada 8.2 - kami menukar konfigurasi UPP 1.2... kepada 1.3.22.1. Sehubungan itu, banyak perbezaan daripada konfigurasi standard yang telah dilancarkan membawa kepada banyak ralat. Selama dua hari, tanpa bermalam, kami menukar konfigurasi tanpa henti. Konfigurator disimpan 15 kali sejam. Adalah dijangkakan bahawa apabila menyimpan, konfigurasi mungkin ranap, itulah yang berlaku. Masalah sedemikian, dalam conf 8.1, sentiasa diselesaikan dengan keluar pengguna yang masih bekerja dalam pangkalan data, tetapi tidak boleh log masuk lagi dan dengan akses eksklusif. Dalam konfigurasi baharu kami 8.2, pangkalan data memberitahu kami "Saya penat. Saya akan pergi"), secara umum masalah diterangkan dalam pengumuman.
Apa yang dilakukan betul dan salah. Dan nasihat tentang apa yang perlu dilakukan terlebih dahulu.
Pertama sekali, dalam kegawatan, kami mula mencari cara untuk menyelesaikan masalah di Internet. Google memberikan secara literal 3 artikel pada masa ini mengenai teks ralat yang berlaku. Saya akan senaraikan mereka.
Secara umum, dalam ketiga-tiga artikel jawapan kepada penyelesaian kepada masalah semasa adalah sama - "Pulihkan pangkalan data daripada sandaran."
Tidak perlu bercakap tentang kepentingan sandaran, keteraturan mereka dan sebagainya. Saya fikir dari segi kami ini adalah amaran yang baik, walaupun kami mempunyai sandaran pangkalan data selepas ia disimpan dalam konfigurasi 1.3, tetapi beberapa orang mengikuti keteraturan mereka dan hakikat bahawa ia telah selesai (dan cakera keras tidak dibersihkan , dan lain-lain.). Oleh itu, maafkan "Captain Obviousness", tetapi jika anda mempunyai sandaran baru, perkara pertama yang perlu dilakukan ialah memulihkan pangkalan data daripadanya, jangan buang masa yang berharga, yang mana pihak pengurusan tidak akan berterima kasih kepada anda untuk masa henti. Walau bagaimanapun, anda boleh cuba menghidupkan semula pangkalan "jatuh", yang, terima kasih kepada kegigihan saya, telah dilakukan. Saya perhatikan bahawa pengaturcara lain juga membuat percubaan untuk menghidupkan semula pangkalan data menggunakan kaedah 1C, tetapi mereka tidak berjaya. Saya tidak tahu semua yang dia lakukan, tetapi saya melihat percubaan untuk melancarkan 1C dalam mod arahan serta-merta dengan pelancaran Pengujian dan Pembetulan Keselamatan Maklumat, yang sebenarnya tidak melancarkan apa-apa.
Saya menumpukan perhatian saya pada SQL. Saya biasa dengan sedikit pengalaman dalam mengkonfigurasi dan mentadbir pangkalan data dan set biasa perintah SQL, tetapi kaedah yang digariskan di bawah tidak memerlukan pengetahuan dan kemahiran mendalam dalam bekerja dengan SQL. Saya hanya menyambungkan logik - jika pangkalan data "jatuh" semasa menyimpan konfigurasi, kami menyimpulkan bahawa struktur satu jadual dalam SQL mungkin telah runtuh (walaupun saya tidak tahu sebelum ini bahawa konfigurasi dalam versi 8 berada dalam satu jadual sekuel) dan jadual ini di mana ia disimpan konfigurasi pangkalan data. iaitu jadual dbo.config. Saya kemudiannya mengetahui menggunakan kaedah "pilih-anda-sendiri" dan, sekali lagi, logik, kerana satu-satunya perkara yang saya dapati adalah pembangunan tempatan, yang tidak membantu saya tetapi agak berguna untuk masa depan, iaitu Terima kasih kepada pengarang daripada akaun rakan sekerja saya, dengan bantuan siapa saya memuat turunnya. Jadi saya beralih kepada perkara yang paling penting - percubaan (!) untuk memulihkan pangkalan data kerana, malangnya, saya tidak dapat memberi anda sebarang jaminan dan terdapat beberapa pratetap yang mungkin tidak anda miliki atau, seperti yang mereka katakan, ini bukan anda kes...
Keperluan dan pemulihan pangkalan data itu sendiri.
(Perhatian. Pastikan anda melihat nota kaki di bawah jika anda ingin cuba menghidupkan semula konfigurasi itu sendiri. Hari ini (18/04/2012) melalui eksperimen saya berjaya kerana saya berasa kesal dengan kerja selama seminggu yang dilakukan ke atasnya. Oleh itu, adalah mungkin untuk menghidupkan semula pangkalan data, meninggalkan konfigurasi lama tanpa sebarang salinan)
Data awal - pangkalan data SQL 1C 8.2, konfigurasi UPP 1.3.22.1 (Saya percaya kaedah yang diterangkan sesuai untuk mana-mana pangkalan data standard 8.2). Pelayan SQL 2005. Ralat yang diterangkan dalam pengumuman dan ralat yang berlaku semasa menyimpan konfigurasi! Syarat paling penting dan wajib!!! Salinan pangkalan data SQL dengan SAME CONFIGURATION(!) Kami telah mengkonfigurasi pertukaran automatik dengan pangkalan data lain dan konfigurasinya adalah sama. Di samping itu, memandangkan kami adalah tiga pengaturcara 1C, kami masing-masing mempunyai fail conf yang dimuat naik dan agak terkini. Malah, mana-mana pangkalan data akan berfungsi, tidak kira apa data, perkara utama ialah konfigurasi di dalamnya sepadan dengan struktur metadata pangkalan data. Saya ingin ambil perhatian bahawa konfigurasi adalah sedikit berbeza daripada yang asasnya terhempas. Keperluan paling asas, pada pendapat saya, ialah perbezaan dalam konfigurasi tidak menjejaskan metadata. Jangan lupa hakikat bahawa jika konfigurasi berbeza, maka pada akhirnya anda akan menerima pangkalan data yang berfungsi tetapi dengan konfigurasi dari salinan anda.
Proses pemulihan itu sendiri tidak akan membawa anda banyak masa - secara harfiah beberapa minit, tetapi saya sangat mengesyorkan membuat sandaran walaupun pangkalan data "jatuh" terlebih dahulu, tetapi ia boleh mengambil masa. Sebagai contoh, anda akan mempunyai peluang untuk memulihkan pangkalan data dengan melancarkan kembali dari fail log (yang, malangnya, "dilarang" dalam kegawatan pemulihan) atau beberapa kaedah lain. Jadi, izinkan saya mengingatkan anda bahawa di suatu tempat mesti ada pangkalan data SQL, tidak kira apa data, tetapi dengan konfigurasi yang sama. Jika konfigurasi anda ialah konfigurasi standard "tidak disentuh" (yang bermakna masalah ini timbul semasa proses melancarkan konfigurasi standard baharu), anda boleh mencipta pangkalan data kosong baharu dan mengisinya dengan konfigurasi standard yang anda miliki sebelum ini. Jika konfigurasi yang anda temui tidak begitu terkini, fikirkan dan buat keputusan; mungkin perbezaan dengan salinan configurator, yang anda akan dipaksa untuk mengulangi dalam pangkalan data anda, akan mengambil lebih banyak masa dan sumber daripada kehilangan maklumat daripada pangkalan data 1C itu sendiri. Sejenis pedang bermata dua) Jadi...
1. Buat sandaran pangkalan data yang ranap menggunakan SQL.
2. Kami mengosongkan jadual dbo.config pangkalan data kami, yang mengandungi conf kami yang rosak. Ini boleh dilakukan dari SQL Profiler, contohnya dengan menjalankan arahan di dalamnya:
Padam Dari .
di mana Base2009 ialah nama pangkalan yang ranap.
Nota: Saya membaca beberapa maklumat yang tidak disahkan di suatu tempat di internet yang kadangkala membantu mengosongkan jadual dbo.ConfigSave, yang kononnya mengandungi conf yang digulung. Dalam pangkalan data kami ternyata kosong, jadi saya jelas tidak membersihkan meja kosong. Mungkin - anda entah bagaimana boleh menipu dan menghidupkan semula pangkalan data 1C menggunakan jadual ini, tetapi tanpa mengetahui mekanisme bagaimana 1C berfungsi dengan jadual ini, saya tidak akan mengatakan apa-apa dari segi tindakan berhubung dengannya.
3. Salin jadual dari pangkalan data dengan keseluruhan konfigurasi ke pangkalan data kami yang rosak. Dalam kes saya, kedua-dua pangkalan data berada pada pelayan yang sama, jadi arahan salin dalam SQL-Profiler kelihatan seperti ini.
masukkan ke dalam .. pilih * dari ..
di mana base2009 ialah nama pangkalan data yang ranap, BaseCopy ialah nama pangkalan data dengan salinan konfigurasi
4. Kami melancarkan 1C, dan jika berjaya, kami melompat, seperti yang saya lakukan, dengan kegembiraan kerana kami berjaya menghidupkan semula pangkalan data tanpa kehilangan maklumat.
5. (Kapten jelas) kami menyemak, menyahpepijat dan memantau sistem untuk membuat sandaran pangkalan data dan mengambil pendekatan yang sangat bertanggungjawab terhadap proses mengemas kini konfigurasi (kami melakukan ini bukan melalui rangkaian, tetapi sebaiknya pada pelayan, jika boleh membuat sandaran dahulu). Terutama jika versi 1C anda telah menjadi 8.2. Setakat yang saya faham dari artikel di Internet dan dua hari pertama bekerja dengannya, ia lebih sensitif dan berubah-ubah, berbanding 8.1 yang tidak ada masalah seperti itu.
5a. Jika konfigurasi pangkalan data dari mana anda akan menyalin jadual conf masih berbeza (tanpa mempunyai perbezaan dalam metadata, yang telah saya nyatakan), dan di suatu tempat terdapat fail cf anda yang agak segar dengan conf yang tidak dimuatkan - gulungkannya ke pangkalan yang dihidupkan semula . Jika tidak, anda perlu mengulangi semua perbezaan yang ada dengan salinan configurator. Jadi fikirkan semula dan analisa perkara yang lebih penting: kerja anda untuk menukar konfigurasi (dan berapa banyak masa yang anda akan habiskan untuknya) atau kerja pengguna pangkalan data sehingga sandaran terakhir. Dalam kes saya, ia adalah kerja 2 pengaturcara selama 3 jam berbanding kerja kira-kira 100 pengguna selama 1.5 hari, jadi pilihannya jelas.
ZY Boleh saya ingatkan awak sekali lagi? bahawa fungsi pemulihan ini adalah cara tidak berdokumen untuk memulihkan pangkalan data oleh biri-biri 1C (dalam kes khusus keruntuhan pangkalan data yang berlaku semasa menyimpan conf) dan semua yang anda lakukan dilakukan atas bahaya dan risiko anda sendiri, tetapi khususnya dalam kes saya di sana adalah cara lain untuk menghidupkan semula pangkalan data dengan minima. Tiada kehilangan maklumat sedia ada (fail log telah hilang dan sandaran terkini mewakili kehilangan 1.5 hari kerja untuk kira-kira 100 pengguna), jadi, seperti yang mereka katakan, jambatan itu terbakar)
Z.Y.Y. Ini adalah penerbitan pertama saya di sini kerana... Saya pengecut di forum 1C yang lain, tetapi saya dapati sumber ini antara yang paling berguna dari segi perkembangan dan penerbitan yang disiarkan, jadi jangan menilai dengan ketat banyak IF dalam penerbitan ini). Saya sangat gembira jika saya benar-benar membantu seseorang dengan pemulihan pangkalan yang musnah, kerana satu-satunya perkara yang lebih buruk daripada itu ialah perang nuklear)
Z.Y.Y.Y. Selepas 3 minggu, masalah itu berulang dengan sendirinya) Kali ini, penyelesaian hanya mengambil masa beberapa saat (jika anda tidak mengambil kira masa yang diambil untuk membuat sandaran), malah pengguna tidak perlu ditendang keluar .
_____________________________________________________________________________________________________________
Seorang rakan sekerja datang berlari hari ini. Masalah yang sama. Hanya pangkalan data yang diuji dan tidak berfungsi, dan pangkalan data itu sendiri hanya untuknya - tetapi konfigurator adalah penting baginya. Dia menghabiskan seminggu mengusahakannya tanpa sekali memuat naik fail ke cf dan tanpa melancarkan perubahan pada pangkalan data yang berfungsi. Nah, mengapa tidak menggali lebih dalam dengan meja?! Kali ini lebih mudah. Saya membuka SQL Management Studio. Saya membentuk pertanyaan pada jadual untuk medan dengan tarikh pengubahsuaian semasa dan masa apabila pangkalan data ranap - hasilnya memberikan 2 rekod. Yang pertama ialah Field FileName = "commit" Nah, ranap entri ini - dan semuanya berjaya untuk saya! Konfigurator telah hidup dan pangkalan data berfungsi semula. Apa yang perlu dilakukan?!
Jadi, dalam tetingkap SQL Managment Studio yang terbuka, kami mencari pangkalan data kami - buka Jadual, cari jadual dengan conf di hujung senarai dbo.config di atas meja - butang kanan - Buka meja. Seterusnya, dalam tetingkap kanan, turun dalam jadual itu sendiri mengikut abjad ke medan di mana FileName = "commit". Kami pergi ke entri ini - butang kanan tetikus - Padam. Secara umum, kami memadamkan entri dengan fail binari. Seterusnya, kita cuba masukkan conf. Ralat yang sama muncul dahulu. Ia mungkin tidak berjaya? Mari tekan okey. Dan kemudian, sebelum mengeluarkan mesej kedua tentang kemustahilan menyimpan, seperti sebelum ini, komputer mula berfikir. Selepas 30 saat - OH KEAJAIBAN! Konfigurator telah dibuka. Kami cuba menyimpan configurator (selepas menyimpan fail cf). Konfigurator disimpan. Oleh itu, serigala diberi makan dan biri-biri selamat. Saya tidak pasti tentang kefungsian penuh pangkalan data selepas penyalahgunaan sedemikian - jadi saya akan menasihati anda untuk menyusun semula dan mengira semula keputusan pada waktu petang (selepas membuat arkib, sudah tentu). Semoga berjaya dengan pemulihan dan emosi positif anda)
Kami berpindah ke pelayan baharu. Ia menjalankan SQL dan 1C. Berbanding dengan yang lama ia jauh lebih sejuk. Dan ujian Gilev juga mengesahkan ini: terhadap 10-15 pada pelayan lama, ia memberikan 39. Oleh itu, sejurus selepas pembelian, kami memindahkan pangkalan data dan mula bekerja.
Tetapi pada satu ketika sesuatu telah berlaku - pengguna mula mengadu tentang kerja yang lambat. Kami membuat tetapan tertentu untuk pelayan dan perkhidmatan (yang mana adalah topik siaran berasingan) dan memutuskan untuk but semula pelayan, mujurlah kelajuan but semula adalah 2 minit (pada pelayan lain ia adalah sehingga 10). Selepas ini, apabila log masuk ke 1C kami menerima mesej berikut:
"Perhatian!!! Ralat berlaku semasa mengemas kini data selepas penstrukturan semula yang terakhir. Perlukah saya mengulangi kemas kini? "Tidak juga"
Selepas mengklik "Ya" perkara berikut muncul:
“Operasi simpan konfigurasi yang tidak lengkap telah dikesan. Anda mesti menyelesaikan operasi untuk meneruskan."
Perkara pertama yang saya putuskan untuk lakukan ialah CHECKDB dalam Studio Pengurusan - selepas 2 jam menunggu (pangkalan data 500 GB) - semuanya OK.
Saya mendapati maklumat di Internet bahawa ralat yang sama berlaku semasa pengemaskinian dinamik.
Penyelesaian yang dicadangkan dalam talian tidak membantu serta-merta, tetapi bersama-sama dengan tindakan lain mereka memberikan hasil. Jadi apa yang saya lakukan:
Penyelesaian:
- Perkara yang tiada untuk penyelesaian daripada rangkaian:
sp_configure 'benarkan kemas kini', 1
konfigurasi semula dengan menimpa
pergi
2. Letakkan pangkalan data ke dalam mod pemulihan
ubah set pangkalan data EMERGENCY, SINGLE_USER
3. Kami melakukan ujian pangkalan data:
dbcc checkdb('db_name', REPAIR_ALLOW_DATA_LOSS)
4. Keluar dari pangkalan data daripada mod pemulihan:
ubah set pangkalan data DALAM TALIAN, MULTI_USER
5. Pada dasarnya, jika anda yakin bahawa semuanya ok dengan asas itu sendiri, maka anda tidak perlu melakukan mata 2-4. Seterusnya, kami menjalankan dua pertanyaan dalam pemprofil SQL:
padam dari konfigurasi di mana FileName = 'commit'
padam dari konfigurasi di mana FileName = 'dbStruFinal'Rekod ini bertanggungjawab untuk mengemas kini dinamik - anda tidak perlu takut untuk memadamkannya.
Dalam versi kerja pertanyaan pangkalan data:
pilih * daripada Config WHERE FileName = 'commit'
pilih * daripada Config WHERE FileName = 'dbStruFinal'
akan kosong.
6. kembalikan tetapan:
sp_configure 'benarkan kemas kini', 0
pergi
7. Selepas ini, kami berjaya melancarkan configurator dan pangkalan data mula berfungsi.
Selain itu, pangkalan boleh mula berfungsi selepas mengeluarkan bendera pertama.
Masalah yang dikhaskan oleh artikel ini berlaku apabila konfigurator ranap pada masa pangkalan data sedang disusun semula, iaitu, pada salah satu peringkat terakhir mengemas kini konfigurasi. Penyelesaian yang diterangkan dalam artikel digunakan pada versi pelayan pelanggan 1C: platform Perusahaan, menggunakan MS SQL Server sebagai DBMS.
Gejala mungkin termasuk amaran sistem berikut:
1) Apabila cuba memulakan pangkalan data dalam mod konfigurasi:
2) Apabila cuba memulakan pangkalan data dalam mod perusahaan:
3) Apabila memasuki configurator, sistem juga mungkin menawarkan penyelesaian berikut:
Kita boleh menjawab soalan ini secara afirmatif. Dan selalunya dengan cara ini masalah diselesaikan. Tetapi tidak selalu.
Sistem mungkin membalas persetujuan kami untuk meneruskan kemas kini dengan mesej berikut:
Atau memerlukan akses eksklusif, yang tidak selalunya mudah dalam sistem dengan bilangan pengguna yang besar, dan kadangkala adalah mustahil.
Dalam kes ini, MS SQL Server akan membantu kami. Untuk menyelesaikan masalah kami, sudah cukup untuk melaksanakan skrip berikut secara berurutan (sudah tentu, dalam konteks pangkalan data yang bermasalah).
1) Mula-mula, mari buat salinan jadual Config dan ConfigSave (kemudian, ia boleh dipadamkan).
PILIH *
INTO Config_copy
DARIPADA [Config]
PILIH *
KE DALAM ConfigSave_copy
DARI
Dalam jadual ini maklumat tentang konfigurasi dan kemajuan kemas kini disimpan. Jadual pertama menyimpan maklumat tentang konfigurasi pangkalan data, termasuk data kemas kini terkini. Jadual kedua mengandungi data daripada konfigurasi baharu yang belum disimpan. Dengan menganalisis kandungan jadual ini, sistem menerima data tentang kejayaan (atau tidak berjaya) kemas kini terakhir.
2) Padam semua entri daripada jadual ConfigSave (menyimpan konfigurasi rolling)
PADAM DARI
3) Padamkan tiga entri daripada jadual Config (mereka menyimpan maklumat tentang proses kemas kini konfigurasi yang belum selesai)
PADAM DARI
DI MANA Nama Fail DALAM ("komit" , "dbStruFinal" , "dynamicCommit")
Rekod tentang kemas kini terbaharu kami harus dipaparkan dalam jadual Config, yang mudah disemak dengan "pilihan" biasa.
