You can move the report server databases that are used in a current installation to a SQL Server Database Engine instance that is on a different computer. Both the reportserver and reportservertempdb databases must be moved or copied together. A Reporting Services installation requires both databases; the reportservertempdb database must be related by name to the primary reportserver database you are moving.
Moving a database does not effect scheduled operations that are currently defined for report server items.
Schedules will be recreated the first time that you restart the Report Server service.
SQL Server Agent jobs that are used to trigger a schedule will be recreated on the new database instance. You do not have to move the jobs to the new computer, but you might want to delete jobs on the computer that will no longer be used.
Subscriptions, cached reports, and snapshots are preserved in the moved database. If a snapshot is not picking up refreshed data after the database is moved, clear the snapshot options in Report Manager, click Apply to save your changes, re-create the schedule, and click Apply again to save your changes.
Temporary report and user session data that is stored in reportservertempdb are persisted when you move that database.
SQL Server provides several approaches for moving databases, including backup and restore, attach and detach, and copy. Not all approaches are appropriate for relocating an existing database to a new server instance. The approach that you should use to move the report server database will vary depending on your system availability requirements. The easiest way to move the report server databases is to attach and detach them. However, this approach requires that you take the report server offline while you detach the database. Backup and restore is a better choice if you want to minimize service disruptions, but you must run Transact-SQL commands to perform the operations. Copying the database is not recommended (specifically, by using the Copy Database Wizard); it does not preserve permission settings in the database.
Important
The steps provided in this topic are recommended when relocating the report server database is the only change you are making to the existing installation. Migrating an entire Reporting Services installation (that is, moving the database and changing the identity of the Report Server Windows service that uses the database) requires connection reconfiguration and an encryption key reset. For more information about migrating a Reporting Services installation, see Migration (Reporting Services).
Detaching and Attaching the Report Server Databases
--------------------------------------------------------------------------------
If you can take the report server offline, you can detach the databases to move them to the SQL Server instance you want to use. This approach preserves permissions in the databases. If you are using a SQL Server 2008 database, you must move it to another SQL Server 2008 instance. After you move the databases, you must reconfigure the report server connection to the report server database. If you are running a scale-out deployment, you must reconfigure the report server database connection for each report server in the deployment.
Use the following steps to move the databases:
1.Backup the encryption keys for the report server database you want to move. You can use the Reporting Services Configuration tool backup the keys.
2.Stop the Report Server service. You can use the Reporting Services Configuration tool to stop the service.
3.Start SQL Server Management Studio and open a connection to the SQL Server instance that hosts the report server databases.
4.Right-click the report server database, point to Tasks, and click Detach. Repeat this step for the report server temporary database.
5.Copy or move the .mdf and .ldf files to the Data folder of the SQL Server instance you want to use. Because you are moving two databases, make sure that you move or copy all four files.
6.In Management Studio, open a connection to the new SQL Server instance that will host the report server databases.
7.Right-click the Databases node, and then click Attach.
8.Click Add to select the report server database .mdf and .ldf files that you want to attach. Repeat this step for the report server temporary database.
9.After the databases are attached, verify that the RSExecRole is a database role in the report server database and temporary database. RSExecRole must have select, insert, update, delete, and reference permissions on the report server database tables, and execute permissions on the stored procedures. For more information, see How to: Create the RSExecRole.
10.Start the Reporting Services Configuration tool and open a connection to the report server.
11.On the Database page, select the new SQL Server instance, and then click Connect.
12.Select the report server database that you just moved, and then click Apply.
13.On the Encryption Keys page, click Restore. Specify the file that contains the backup copy of the keys and the password to unlock the file.
14.Restart the Report Server service.
Backing Up and Restoring the Report Server Databases
--------------------------------------------------------------------------------
If you cannot take the report server offline, you can use backup and restore to relocate the report server databases. You should use the ‘Copy_Only’ option. Beginning in SQL Server 2008, SQL Server Management Studio supports copy-only backups. After you restore the databases, you must configure the report server to use the database on the new server instance. For more information, see the instructions at the end of this topic.
Using BACKUP and COPY_Only to Backup the Report Server Databases
When backing up the databases, set the COPY_OnlyL option and backup type to Full.
Note
Be sure to back up both the ReportServer and ReportServerTempDB databases as well as their associated log files.
For more information on using SQL Server Management Studio to backup a database, see How to: Back Up a Database (SQL Server Management Studio)
Using RESTORE and MOVE to Relocate the Report Server Databases
When restoring the databases, you can Use the RESTORE WITH NORECOVERY argument to perform the initial restore; this keeps the database in a restoring state, giving you time to review log backups to determine which one to restore. You would then repeat the RESTORE operation but use the RESTORE WITH RECOVERY argument.
Note
Be sure to restore both the ReportServer and ReportServerTempDB databases as well as their associated log files.
For more information on using SQL Server Management Studio to restore a database, see How to: Restore a Database Backup (SQL Server Management Studio)
How to Configure the Report Server Database Connection
1.Start the Reporting Services Configuration tool and open a connection to the report server.
2.On the Database page, click Change Database. Click Next.
3.Click Choose an existing report server database. Click Next.
4.Select the SQL Server that now hosts the report server database and click Test Connection. Click Next.
5.In Database Name, select the report server database that you want to use. Click Next.
6.In Credentials, specify the credentials that the report server will use to connect to the report server database. Click Next.
7.Click Next and then Finish.
Note
A Reporting Services installation requires that the SQL Server Database Engine instance include the RSExecRole role. Role creation, login registration, and role assignments occur when you set the report server database connection through the Reporting Services Configuration tool. If you use alternate approaches (specifically, if you use the rsconfig.exe command prompt utility) to configure the connection, the report server will not be in a working state. You might have to write WMI code to make the report server available. For more information, see Reporting Services WMI Provider.
Tuesday, July 12, 2011
How to enable WCF tracing
Open config file in svcconfigeditor, from wizard, you can enable tracing and logging
STEP1:
Open config file in svcconfigeditor
STEP2:
Select Diagnostics option on left side, you will see Different tracing options on right side
STEP3:
If you just want to log soap request and response, you can choose Message Tracing
If you want trace service creation and all other activities, you can enable service tracing
Once you choose one of those options, you can choose, what level of tracing you want
(Like Verbose, or you want trace only error messages)
STEP4:
Click on Message Tracing, you will see different Message logging options, you can choose, you want to log Message at Transport level or Service level.
Reference:
http://msdn.microsoft.com/en-us/library/ms732009.aspx
Ok, Now I got trace file, How to view trace file:
Once you have log file, you can open client side trace and service side trace file in svctraceviewer and you can filter trace by different categories
http://windowssdk.msdn.microsoft.com/en-us/library/ms732023.aspx
Tracing and Logging Sample
http://msdn.microsoft.com/en-us/library/ms751526.aspx
MORE INFO ABOUT WMI AND PERF COUNTERS:
http://msdn.microsoft.com/en-us/library/ms735120.aspx
http://msdn.microsoft.com/en-us/library/ms735098.aspx
http://msdn.microsoft.com/en-us/library/ms751442.aspx
http://msdn.microsoft.com/en-us/library/ms751407.aspx
MORE INFO:
The Diagnostics tab enables you to turn performance counters on or off, enable or disable Windows Management Instrumentation (WMI), configure WCF tracing, and configure Windows Communication Foundation (WCF) message logging.
To control performance counters and WMI
Click the Diagnostics tab.
To turn on WCF performance counters, select the Enable Performance Counters check box. Clear the box to turn off the counters.
To turn on WMI, select the Enable WMI check box. Clear the box to disable WMI.
Configuring Tracing
You can create a WCF trace file with standard properties or set up a custom trace file.
To create a trace file with standard properties
Click the Diagnostics tab and click Tracing.
In the Diagnostics Tracing window that opens, click Create.
Choose a location for the trace file, and click Save.
Click OK to return to the Service Configuration Editor window.
To create a custom WCF trace file, you must configure both a source and listener.
To create a custom WCF trace file
Click the Diagnostics tab, and then click Tracing.
In the Diagnostics Tracing window that opens, on the Listeners tab, click Add.
Enter the parameters for your trace file. Clicking the TypeName line displays a "…" button. Click the "…" button to open Trace Listener Type Browser, which you can use to find preconfigured trace listeners that are already installed.
Note the Source section. Click Add in this section to open a dialog box with a drop-down menu listing available tracing sources. Select a tracing source and click OK.
To apply your changes, click OK on each window until you return to the main Service Configuration Editor window.
Configuring Message Logging
You can create a WCF message logging file with standard properties or set up a custom logging file.
To create a message logging file with standard properties
Click the Diagnostics tab and click Logging.
In the Message Logging Editor window that opens, click the Create button.
Choose a location for the log file and click Save.
Click OK to return to the Service Configuration Editor window.
To create a custom WCF message logging file, you must configure a source and a listener, as well as certain parameters.
To create a custom WCF message logging file
Click the Diagnostics tab and click Logging.
In the Message Logging Editor window that opens, on the Listeners tab, click Add.
Enter the parameters for your trace file. Clicking the TypeName line displays a "…" button. Click the "…" button to open the Trace Listener Type Browser, which you can use to find preconfigured trace listeners that are already installed.
Note the Source section. Click Add in this section to open a dialog box with a drop-down menu listing available tracing sources. Select a tracing source and click OK.
Click the Logging tab to set logging parameters. For example, you might want to set LogEntireMessage to False to help manage the size of log files.
To apply your changes, click OK on each window until you return to the main Service Configuration Editor window.
STEP1:
Open config file in svcconfigeditor
STEP2:
Select Diagnostics option on left side, you will see Different tracing options on right side
STEP3:
If you just want to log soap request and response, you can choose Message Tracing
If you want trace service creation and all other activities, you can enable service tracing
Once you choose one of those options, you can choose, what level of tracing you want
(Like Verbose, or you want trace only error messages)
STEP4:
Click on Message Tracing, you will see different Message logging options, you can choose, you want to log Message at Transport level or Service level.
Reference:
http://msdn.microsoft.com/en-us/library/ms732009.aspx
Ok, Now I got trace file, How to view trace file:
Once you have log file, you can open client side trace and service side trace file in svctraceviewer and you can filter trace by different categories
http://windowssdk.msdn.microsoft.com/en-us/library/ms732023.aspx
Tracing and Logging Sample
http://msdn.microsoft.com/en-us/library/ms751526.aspx
MORE INFO ABOUT WMI AND PERF COUNTERS:
http://msdn.microsoft.com/en-us/library/ms735120.aspx
http://msdn.microsoft.com/en-us/library/ms735098.aspx
http://msdn.microsoft.com/en-us/library/ms751442.aspx
http://msdn.microsoft.com/en-us/library/ms751407.aspx
MORE INFO:
The Diagnostics tab enables you to turn performance counters on or off, enable or disable Windows Management Instrumentation (WMI), configure WCF tracing, and configure Windows Communication Foundation (WCF) message logging.
To control performance counters and WMI
Click the Diagnostics tab.
To turn on WCF performance counters, select the Enable Performance Counters check box. Clear the box to turn off the counters.
To turn on WMI, select the Enable WMI check box. Clear the box to disable WMI.
Configuring Tracing
You can create a WCF trace file with standard properties or set up a custom trace file.
To create a trace file with standard properties
Click the Diagnostics tab and click Tracing.
In the Diagnostics Tracing window that opens, click Create.
Choose a location for the trace file, and click Save.
Click OK to return to the Service Configuration Editor window.
To create a custom WCF trace file, you must configure both a source and listener.
To create a custom WCF trace file
Click the Diagnostics tab, and then click Tracing.
In the Diagnostics Tracing window that opens, on the Listeners tab, click Add.
Enter the parameters for your trace file. Clicking the TypeName line displays a "…" button. Click the "…" button to open Trace Listener Type Browser, which you can use to find preconfigured trace listeners that are already installed.
Note the Source section. Click Add in this section to open a dialog box with a drop-down menu listing available tracing sources. Select a tracing source and click OK.
To apply your changes, click OK on each window until you return to the main Service Configuration Editor window.
Configuring Message Logging
You can create a WCF message logging file with standard properties or set up a custom logging file.
To create a message logging file with standard properties
Click the Diagnostics tab and click Logging.
In the Message Logging Editor window that opens, click the Create button.
Choose a location for the log file and click Save.
Click OK to return to the Service Configuration Editor window.
To create a custom WCF message logging file, you must configure a source and a listener, as well as certain parameters.
To create a custom WCF message logging file
Click the Diagnostics tab and click Logging.
In the Message Logging Editor window that opens, on the Listeners tab, click Add.
Enter the parameters for your trace file. Clicking the TypeName line displays a "…" button. Click the "…" button to open the Trace Listener Type Browser, which you can use to find preconfigured trace listeners that are already installed.
Note the Source section. Click Add in this section to open a dialog box with a drop-down menu listing available tracing sources. Select a tracing source and click OK.
Click the Logging tab to set logging parameters. For example, you might want to set LogEntireMessage to False to help manage the size of log files.
To apply your changes, click OK on each window until you return to the main Service Configuration Editor window.
Monday, July 11, 2011
Some limitations of Entity Framework 4 (EF4)
EF4 problems:
Eager Loading and shaping the result: EF4 eager loading system (Include("Path")) generates improper SQL, with looping JOIN's , which will execute thousands(not literally) time slower for many-to-many relationships then hand written SQL (it's effectively unusable).
Materializer can't materialize associated entities: If you can think you can overcome previous problem by providing you own SQL query, you are wrong. EF4 can't materialize(map) associated entities from JOIN SQL query, it can only load data from one table (So if you have Order.Product, SELECT * FROM order LEFT JOIN Product will initialize only Order object, Product will remain null, thought all necessary data is fetched in query to init it ). This can be overcome by using EFExtensions community add-on, but the code you will have to write for this is really ugly (I tried).
Self-Tracking Entities: Many say that Self-tracking entities are cool for N-tier development including the top answer in this thread. Thought I haven't even give them a try, I can say they are not.Every input can be forged, you can't simply take the changes that user sends you and apply them to data base, why not give the user direct data base access then? Any way you will have to load the data user is about to change from DB, check that it exist
not exists do permissions checks etc etc. You can't trust user on the state of entity he is sending to server, you will anyway have to load this entity from DB and determine it's state and other things, so this information is useless, as do Self-Tracking entities unless you do a private trusted n-tier system for internal use, in which case maybe you could give just plain DB access. (Thats my thoughts about ST Entities and N-tire, I'm not very expericned in N-Tier, so it can change, if I misunderstood something here comment it)
Logging, Events, integrating business logic: EF4 is like black box, it do something and you have no idea what it do. There is only one event OnSavingChanges where you can put some business logic you need to run before something happens with DB, and if you need to apply some changes to business objects before something happens you will have to dig in ObjectStateManager, and this is really ugly, code can become huge. If you for example using Repository pattern and what to be notified on changes made to DB in clean object way, you will have hard time doing this with EF.
Extensibility: All EF code is private and internal, if you don't like something (and you will not like a LOT if you are serious about EF using), no way you will change this in easy way, In fact I'm sure it's easer to write you own ORM from scratch (I did) then make EF work as you need. As example take a look at EFExtensions source, it's based on extensions methods, and different "hacks" to make EF little more usable, and the code is pretty ugly (and it's not authors fault, when everything in EF is private this is the only way to extend it).
Eager Loading and shaping the result: EF4 eager loading system (Include("Path")) generates improper SQL, with looping JOIN's , which will execute thousands(not literally) time slower for many-to-many relationships then hand written SQL (it's effectively unusable).
Materializer can't materialize associated entities: If you can think you can overcome previous problem by providing you own SQL query, you are wrong. EF4 can't materialize(map) associated entities from JOIN SQL query, it can only load data from one table (So if you have Order.Product, SELECT * FROM order LEFT JOIN Product will initialize only Order object, Product will remain null, thought all necessary data is fetched in query to init it ). This can be overcome by using EFExtensions community add-on, but the code you will have to write for this is really ugly (I tried).
Self-Tracking Entities: Many say that Self-tracking entities are cool for N-tier development including the top answer in this thread. Thought I haven't even give them a try, I can say they are not.Every input can be forged, you can't simply take the changes that user sends you and apply them to data base, why not give the user direct data base access then? Any way you will have to load the data user is about to change from DB, check that it exist
not exists do permissions checks etc etc. You can't trust user on the state of entity he is sending to server, you will anyway have to load this entity from DB and determine it's state and other things, so this information is useless, as do Self-Tracking entities unless you do a private trusted n-tier system for internal use, in which case maybe you could give just plain DB access. (Thats my thoughts about ST Entities and N-tire, I'm not very expericned in N-Tier, so it can change, if I misunderstood something here comment it)
Logging, Events, integrating business logic: EF4 is like black box, it do something and you have no idea what it do. There is only one event OnSavingChanges where you can put some business logic you need to run before something happens with DB, and if you need to apply some changes to business objects before something happens you will have to dig in ObjectStateManager, and this is really ugly, code can become huge. If you for example using Repository pattern and what to be notified on changes made to DB in clean object way, you will have hard time doing this with EF.
Extensibility: All EF code is private and internal, if you don't like something (and you will not like a LOT if you are serious about EF using), no way you will change this in easy way, In fact I'm sure it's easer to write you own ORM from scratch (I did) then make EF work as you need. As example take a look at EFExtensions source, it's based on extensions methods, and different "hacks" to make EF little more usable, and the code is pretty ugly (and it's not authors fault, when everything in EF is private this is the only way to extend it).
Subscribe to:
Posts (Atom)