dinsdag 27 september 2011
BTS Project build error on string message
Today Is was making an orchestration that contains a Multi-Part message type, with a message part of type System.String.
When building the BizTalk Project it returned the error "'System.String' must be Xml serializable to be a message part type".
I've tried several things, but it kept giving this same error no matter what I tried.
But I was certain I had used System.String parts in an orchestration before, without any problems.
So after some debugging, I tried restarting Visual Studio... and this seemed to do the trick!
Apparantly all ik took to succesfully build the biztalk project was restarting Visual Studio.
woensdag 14 september 2011
BUILD conference keynote summary
Here you can find a summary of the Windows BUILD conference keynote on Windows 8:
BUILD conference: impressions of Windows 8 keynote news - ctodx
BUILD conference: impressions of Windows 8 keynote news - ctodx
donderdag 8 september 2011
SQL Recovery Models explained
There are 3 different recovery models available in Microsoft SQL Server. However, the understanding of the differences between those recovery models doesn't seem to be well understood. That's why I decided to give a little summary of each of the recovery models.
To continue, I first need to explain the differences of logging levels
Minimal logging indicates it only logs the information that is required to recover the transaction without supporting point-in-time recovery. An operation is said to be minimally-logged if all it logs are the allocation changes. That means that there is not sufficient information in the log to replay the transaction.
So for example when doing a bulk insert only the allocations will be logged, not the inserted rows or the data on the pages. So this transaction can't be reproduced just by the information that was logged. SQL would be able to reallocate the pages, but it can't put the correct data in these pages.
A complete list of operations that will be minimally logged can be found here.
An operation is said to be fully logged if all information needed to reproduce the operation can be found in the logged information. This doesn't mean that for each operation every row will be individually logged in the transaction log. When doing a truncate on a table for example, it will only log the page de-allocations. But since this information is enough to reproduce the operation, it is still classified as fully logged.
Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.
The simple recovery model minimizes administrative overhead for the transaction log, because the transaction log is not backed up. The simple recovery model risks significant work-loss exposure if the database is damaged. Data is recoverable only to the most recent backup of the lost data. Therefore, under the simple recovery model, the backup intervals should be short enough to prevent the loss of significant amounts of data. However, the intervals should be long enough to keep the backup overhead from affecting production work. Including differential backups in the backup strategy can help reduce the overhead.
Generally, for a user database, the simple recovery model is useful for test and development databases or for databases containing mostly read-only data, such as a data warehouse. The simple recovery model is inappropriate for production systems where loss of recent changes is unacceptable. In such cases, we recommend using the full recovery model.
More information: Backup Under the Simple Recovery Model
Provides the normal database maintenance model for databases where durability of transactions is necessary.
Log backups are required. This model fully logs all transactions and retains the transaction log records until after they are backed up. The full recovery model allows a database to be recovered to the point of failure, assuming that the tail of the log can be backed up after the failure. The full recovery model also supports restoring individual data pages.
More information: Backup Under the Full Recovery Model
This recovery model bulk logs most bulk operations. It is intended solely as an adjunct to the full recovery model. For certain large-scale bulk operations such as bulk import or index creation, switching temporarily to the bulk-logged recovery model increases performance and reduces log space consumption. Log backups are still required. Like the full recovery model, the bulk-logged recovery model retains transaction log records until after they are backed up. The tradeoffs are bigger log backups and increased work-loss exposure because the bulk-logged recovery model does not support point-in-time recovery.
For a database that uses full recovery, switching to the bulk-logged recovery model temporarily for bulk operations improves performance. However, if data loss is unacceptable, to prevent data loss, it isrecommended that you switch to the bulk-logged recovery model only under the following conditions:
More information: Backup Under the Bulk-Logged Recovery Model
To continue, I first need to explain the differences of logging levels
Logging Levels
Minimally logging
Minimal logging indicates it only logs the information that is required to recover the transaction without supporting point-in-time recovery. An operation is said to be minimally-logged if all it logs are the allocation changes. That means that there is not sufficient information in the log to replay the transaction.
So for example when doing a bulk insert only the allocations will be logged, not the inserted rows or the data on the pages. So this transaction can't be reproduced just by the information that was logged. SQL would be able to reallocate the pages, but it can't put the correct data in these pages.
A complete list of operations that will be minimally logged can be found here.
Fully logging
An operation is said to be fully logged if all information needed to reproduce the operation can be found in the logged information. This doesn't mean that for each operation every row will be individually logged in the transaction log. When doing a truncate on a table for example, it will only log the page de-allocations. But since this information is enough to reproduce the operation, it is still classified as fully logged.
In conclusion
Minimal logging is more efficient than full logging, and it reduces the possibility of a large-scale bulk operation filling the available transaction log space during a bulk transaction. However, if the database is damaged or lost when minimal logging is in effect, you cannot recover the database to the point of failure.
Recovery Models
Simple Recovery Model
The simple recovery model minimizes administrative overhead for the transaction log, because the transaction log is not backed up. The simple recovery model risks significant work-loss exposure if the database is damaged. Data is recoverable only to the most recent backup of the lost data. Therefore, under the simple recovery model, the backup intervals should be short enough to prevent the loss of significant amounts of data. However, the intervals should be long enough to keep the backup overhead from affecting production work. Including differential backups in the backup strategy can help reduce the overhead.
Generally, for a user database, the simple recovery model is useful for test and development databases or for databases containing mostly read-only data, such as a data warehouse. The simple recovery model is inappropriate for production systems where loss of recent changes is unacceptable. In such cases, we recommend using the full recovery model.
More information: Backup Under the Simple Recovery Model
Full Recovery Model
Provides the normal database maintenance model for databases where durability of transactions is necessary.
Log backups are required. This model fully logs all transactions and retains the transaction log records until after they are backed up. The full recovery model allows a database to be recovered to the point of failure, assuming that the tail of the log can be backed up after the failure. The full recovery model also supports restoring individual data pages.
More information: Backup Under the Full Recovery Model
Bulk-Logged Recovery Model
This recovery model bulk logs most bulk operations. It is intended solely as an adjunct to the full recovery model. For certain large-scale bulk operations such as bulk import or index creation, switching temporarily to the bulk-logged recovery model increases performance and reduces log space consumption. Log backups are still required. Like the full recovery model, the bulk-logged recovery model retains transaction log records until after they are backed up. The tradeoffs are bigger log backups and increased work-loss exposure because the bulk-logged recovery model does not support point-in-time recovery.
For a database that uses full recovery, switching to the bulk-logged recovery model temporarily for bulk operations improves performance. However, if data loss is unacceptable, to prevent data loss, it isrecommended that you switch to the bulk-logged recovery model only under the following conditions:
- Users are currently not allowed in the database.
- No modifications are made during bulk processing that are not recoverable without depending on taking a log backup; for example, by re-running the bulk processes.
- Before switching to the bulk-logged recovery model, you back up the log.This is important because, under the bulk-logged recovery model, if the database fails, backing up the log for bulk operations requires access to the data.
- After performing the bulk operations, you immediately switch back to full recovery mode.
- After switching back from the bulk-logged recovery model to the full recovery model, you back up the log again.
More information: Backup Under the Bulk-Logged Recovery Model
Summary of recovery models
Recovery model | Description | Work loss exposure | Recover to point in time? |
|---|---|---|---|
Simple | No log backups. Automatically reclaims log space to keep space requirements small, essentially eliminating the need to manage the transaction log space. | Changes since the most recent backup are unprotected. In the event of a disaster, those changes must be redone. | Can recover only to the end of a backup. |
Full | Requires log backups. No work is lost due to a lost or damaged data file. Can recover to an arbitrary point in time (for example, prior to application or user error). | Normally none. If the tail of the log is damaged, changes since the most recent log backup must be redone. For more information, see Tail-Log Backups. | Can recover to a specific point in time, assuming that your backups are complete up to that point in time. For more information, see Restoring a Database to a Point Within a Backup. |
Bulk logged | Requires log backups. An adjunct of the full recovery model that permits high-performance bulk copy operations. Reduces log space usage by using minimal logging for most bulk operations. For more information, see Operations That Can Be Minimally Logged. | If the log is damaged or bulk-logged operations occurred since the most recent log backup, changes since that last backup must be redone. Otherwise, no work is lost. | Can recover to the end of any backup. Point-in-time recovery is not supported. |
maandag 29 augustus 2011
SQL Server educational links
Found a great blog post full of links for a better knowledge of SQL Server.
There are multiple links on each of these subjects:
Source: Every .NET Developer Should Know About the Database they are working with
There are multiple links on each of these subjects:
- Identifying SQL Server Bottlenecks and Performance Issues
- Moving Data in SQL Server
- Know your SQL Server Objects and Manipulate them
Source: Every .NET Developer Should Know About the Database they are working with
donderdag 25 augustus 2011
Visual Studio: VS templates missing
I was unable to add an aspx page to my web site solution.
The error I got from Visual Studio was:
"Could not find file 'c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplatesCahce\Web\Csharp\1033\WebForm.zip\WebForm_cb.aspx'."
This was the solution:
The error I got from Visual Studio was:
"Could not find file 'c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplatesCahce\Web\Csharp\1033\WebForm.zip\WebForm_cb.aspx'."
This was the solution:
- Open "Visual Studio 2008 Command Prompt"
- Run the command: "devenv /installvstemplates"
dinsdag 23 augustus 2011
Biztalk Error: The system cannot find the file specified (Exception from HRESULT: 0x80070002)
Each time I tried to test my new mapping using BizTalk I got this error: The system cannot find the file specified (Exception from HRESULT: 0x80070002).
So the full error in the event viewer looked like this:
A message received by adapter "FILE" on receive location "RECEIVE ORDERS PCE FILE" with URI "C:\B2B.TRADCOM.COM\ORDERS\INBOUND\PCE\*.xml" is suspended.
Error details: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
MessageId: {F83F1E4B-3B09-4F9B-A9D5-F6C1BD5C2698}
InstanceID: {E162E5AB-E621-4EA1-B643-FD843D7F8D44}
I was able to map the message using Visual Studio, so I was quite sure my BizTalk mapping was correct.
Now it turned out that I forgot to sign the assembly. So the system was unable to place the assembly in the GAC. Because I used a deploy script I didn't notice the resulting warning.
So the full error in the event viewer looked like this:
A message received by adapter "FILE" on receive location "RECEIVE ORDERS PCE FILE" with URI "C:\B2B.TRADCOM.COM\ORDERS\INBOUND\PCE\*.xml" is suspended.
Error details: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
MessageId: {F83F1E4B-3B09-4F9B-A9D5-F6C1BD5C2698}
InstanceID: {E162E5AB-E621-4EA1-B643-FD843D7F8D44}
I was able to map the message using Visual Studio, so I was quite sure my BizTalk mapping was correct.
Now it turned out that I forgot to sign the assembly. So the system was unable to place the assembly in the GAC. Because I used a deploy script I didn't notice the resulting warning.
woensdag 17 augustus 2011
The Mystery of Query Timeouts by Kendra Little - YouTube
"People are complaining about query timeouts. I don't see anything happening in SQL Server, but they always say the database is the problem. How can I tell what's really going on?"
When your users keep hitting timeouts in their application, they naturally think the database is killing off helpless queries. In this webinar Kendra Little will tell you how to triage treacherous timeout situations and collect hard evidence about whether or not the problem is in the database. Do the right detective work and you can turn your frustrated users and irate developers into raving fans.
This session is be 200-level - you should have familiarity with OLTP concepts and understand what DMVs and Profiler are, but you don't have to be an expert with them.
When your users keep hitting timeouts in their application, they naturally think the database is killing off helpless queries. In this webinar Kendra Little will tell you how to triage treacherous timeout situations and collect hard evidence about whether or not the problem is in the database. Do the right detective work and you can turn your frustrated users and irate developers into raving fans.
This session is be 200-level - you should have familiarity with OLTP concepts and understand what DMVs and Profiler are, but you don't have to be an expert with them.
Abonneren op:
Posts (Atom)