Kevin Holman сравнивает свой опыт переноса БД с официальной документацией http://technet.microsoft.com/en-us/library/cc540384.aspx.
Вполне резонные замечания :)
* In step 1, I install and configure SQL on the new server. I verify I have configured this SQL server with my corporate security standards, and I have SA rights on this server.
* In step 2 – the guide states to back up the OpsDB. I DISAGREE with this step. The reason for this is that step 3 tells us to then stop the OpsMgr services after the backup in step 2, and I feel this is a bad idea. The reason is simply because in between the time of the backup, and the time we stop all the services – the Management servers are STILL WRITING to both databases. When we restore our backup to the new server, it will be out of synch with the Warehouse database from an alert and state change event perspective, and this can wreak some havoc on alert detail reports and availability reports. What we SHOULD do is FIRST stop all the core OpsMgr services on the RMS and all MS, and THEN take the backup/restore of the OpsDB. This ensures our two database stay in synch. It looks like the guide didn’t take into consideration the existence of a warehouse DB. Therefore – MY recommendation for step 2 will be to perform the steps in “Step 3” (stop all services), FIRST.
* After I confirm all services are stopped – I take a full backup of the Ops DB.
* In step 4, I uninstall the OpsDB component from the old server. I get an error about failed to run a SQL script. Ignored. :-)
* In step 5, I (gasp) delete the OperationsManager database. (if you are concerned – you might consider restoring the backup to the new server first – to make sure the backup/restore works before taking this drastic step.
* In step 6, I restore my backup of OperationsManager to the new server.
* In step 7, I edit the registry of each RMS\MS server, with my new server\instance name. (SQLDB1\I01). I DO NOT do step 7f. Step 7F would have use start up the RMS and MS services. This SHOULD NOT be done – as there is further configuration that should be done first, editing the DB for the correct name, and establishing the correct account rights. I recommend leaving these services stopped until this is completed. The services will just error out until these later steps are performed.
* In step 8 – I modify the database table per the guide.
* In step 9 – I add my SDK account login to SQL and make sure the mappings are correct.
* In step 10 – I add my Management Server Action Account login and set/verify permissions.
* In step 11 – I add my Data Warehouse Action Account login and set/verify permissions. (Hint – this is your Data Warehouse Write Account) I wish we didn’t have so many different names for the same things.
* Last in the guide – I set ENABLE BROKER per the instructions.
*** Note – there is a footnote added by a user in the guide to enable CLR. This is REQUIRED… it is missing from the core guide.
In order to support regular expressions in Operations Manager SQL queries, the development team needed to create CLR functions that use .NET's RegEx library. Operations Manager Setup configures SQL to allow execution of the CLR code. When the customer in this case moved the database from one SQL server to another they lost this setting in the OperationsManager Database.
To resolve this issue run the following query on the OperationsManager database:
sp_configure @configname=clr_enabled, @configvalue=1
GO
Let that command execute successfully then run
RECONFIGURE
GO
This will correct the issue above.
* NOW – we can start up our services on the RMS and MS, and check for error events and validate everything is working.
Mine actually failed. I forgot to open the SQL program and ports in the Windows Firewall. I created a rule for the SQLServer.exe program, and another for UDP 1434 (for SQL browser) and all was well.
I started my services and validated everything is working and no bad events showing up in the RMS/MS event logs.
Комментариев нет:
Отправить комментарий