Mengapa cermin basis data saya rusak setelah mengubah pengaturan grup file dari RESTRICTED_USER ke MULTI_USER?

9

Lingkungan saya adalah sebagai berikut: VMWare 5.5 vitalized server MS Windows Server 2008R2 Enterprise domain dan SQL Server 2008 R2 Enterprise . Penyimpanan terpusat dengan koneksi saluran serat.

Saya memiliki partisi di partisi saya SQL Server DB. Saya punya 2 file groups: satu dengan data langsung (FG1) , kedua dengan data historis (HDG) .

Grup file kedua adalah read-only. Setiap bulan saya membuat gerakan di partisi - saya menambahkan data baru (dari bulan sebelumnya) ke data historis. Proses ini otomatis .

Kami memindahkan basis data kami ke server baru. Awalnya, saya harus melakukan proses secara manual . Selama operasi ini cermin saya rusak (setelah operasi 3 - lihat aliran proses di bawah) dengan kesalahan berikut:

PADA SERVER UTAMA:

BARIS 0 di LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid84

Message
Setting database option MULTI_USER to ON for database MYDB.

BARIS 1 di LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid18s

Message
Error: 1453, Severity: 16, State: 1.

ROW 2 di LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid18s

Message
'TCP://10.201.27.154:5022', the remote mirroring partner for database 'MYDB', encountered error 823, status 3, severity 24. Database mirroring has been suspended.  Resolve the error on the remote server and resume mirroring, or remove mirroring and re-establish the mirror server instance.

KETERANGAN: Saya menjalankan operasi ini di server lama berkali-kali secara otomatis dan saya tidak pernah mengalami kesalahan seperti itu.

PADA SERVER CERMIN:

BARIS 1 di LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Archive #3 - 15.6.2015 21:33:00)

Source      spid17s

Message
Error: 823, Severity: 24, State: 3.

ROW 2 di LOG:

Date        15.6.2015 20:54:11
Log     SQL Server (Archive #3 - 15.6.2015 21:33:00)

Source      spid17s

Message
The operating system returned error 5(Access is denied.) to SQL Server during a write at offset 0000000000000000 in file 'e:\Databases\MYDB_HISTRICAL.ndf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

PROSES SAYA BERIKUT:

1. Saya membuat beberapa cadangan dari Database (Full, File Group dan TLog backup).

2. Saya mengatur DB ke RESTRICTED_USER(untuk memungkinkan penghapusan read-only dari bendera grup file bersejarah dengan skrip).

2a. Saya menghapus READ-ONLYbendera Grup File Historis saya.

3. Saya mengatur DB MULTI_USERagar memungkinkan pengoperasian normal perangkat lunak kami.

4. Saya memperbarui partisi sehingga data dipindahkan ke grup file historis.

5. Saya ulangi langkah 2 , 2a dan 3 sehingga saya dapat mengatur grup file historis BACA HANYA lagi.

6. Saya membuat cadangan lagi.

Adakah yang tahu mengapa saya menerima kesalahan itu?

EDIT: Kami menerima masalah yang sama selama fase prosedur yang berbeda. Ini adalah satu-satunya situasi di mana cermin rusak jadi saya kira masalahnya ada di dalam prosedur, tapi saya tidak tahu mengapa!

sql-server partitioning mirroring vmware Bogdan Bogdanov
sumber
Error: 823, Severity: 24sepertinya masalah perangkat keras. Periksa DISKS Anda untuk melihat apakah mereka menjadi buruk. Jalankan checkdb pada database untuk memastikan semuanya bersih.
Kin Shah
Saya tidak yakin @Kin. Kami memiliki penyimpanan IBM khusus optik terlampir baru. Ini beroperasi dari sekitar 3 bulan. Dan ini adalah satu-satunya saat kami menerima kesalahan semacam itu. Sebenarnya ada sekitar 10 baris dengan kesalahan itu, tetapi semuanya terjadi selama periode waktu itu. Kami menghancurkan cermin dan membuatnya lagi. Kami memiliki masalah untuk menghapus cermin. Jadi kami menghapusnya secara manual.
Bogdan Bogdanov
Kesalahan 823 with sev 24adalah masalah perangkat keras. Apakah Anda melakukan pencadangan tingkat file alih-alih cadangan server sql asli atau apakah ada perangkat lunak antivirus yang berjalan di server? Anda harus menempatkan peringatan agen sql untuk mengingatkan Anda ketika 823 kesalahan terjadi - skrip ini akan membantu Anda . Juga, 823 adalah kesalahan yang buruk untuk didapatkan - ia mengatakan bahwa operasi I / O gagal pada tingkat OS dan subsistem I / O menyebabkan korupsi - sql server tidak melakukan checsum halaman
Kin Shah
Kami melakukan kedua jenis cadangan, @Kin. Kita juga harus VmWare replicationa remote host. Hal yang saya perhatikan sampai saya menulis jawaban kepada Anda adalah bahwa kami tidak dapat menghancurkan cermin dengan cara normal. File dikunci dan kita perlu stop SQL servicedan untuk memindahkan file db ke direktori lain. Sejak saat itu semuanya baik-baik saja (saya memeriksa log menggunakan sys.xp_readerrorlog). Pikiran lain adalah jika replikasi VmWare terjadi pada saat itu, tetapi saya tidak yakin bagaimana ini akan mempengaruhi proses (saya sedikit tahu tentang VmWare).
Bogdan Bogdanov
We do both type of backupsitu mungkin masalah. Snapshots VM tidak boleh digunakan sebagai alternatif untuk cadangan server sql asli.
Kin Shah

Jawaban:

0

Kami menemukan masalahnya. Ini adalah bug di SQL Server. Ketika kita mengatur READ_WRITEperintah tidak ditransfusikan dengan benar ke dalam mirrorDB. Ketika skrip mulai berubah partitionspada server mirror, terjadi kesalahan. Setelah itu sinkronisasi dihancurkan dan DB di cermin terkunci (dalam suspendedkeadaan).

Kami memperbaiki masalah dengan memperbarui SQL Server ke versi terbaru (versi awal kami adalah wiout SP).

Bogdan Bogdanov
sumber