Showing posts with label Database. Show all posts
Showing posts with label Database. Show all posts

Saturday, September 20, 2014

Failed to create the SQL database Source="SSO"

Recently I tried to configure BizTalk 2010 on which Visual Studio 2010 was already installed.
I could not configure SSO and got the following error message in the log file.

Failed to create the SQL database Source="SSO" HelpID=""><Exception Message="(0xC0002A21) An error occurred while attempting to access the SSO database.

It also said to check the eventlog for more details but there was no error in Eventlog.

Finally I traced the issue that it was because of  the  missing folders on the SQL Server machine so SQL Server could not create the databases and log files.
I found it out by using SQL Profiler and activating all types of Events.
















I knew of many SSO Errors so tried everything like registering SSOSQL.dll and other fixes but never imagined it could be because of SQL not been configured properly.

Monday, August 25, 2014

BizTalk 2013 R2 database migration from SQL 2012 to 2014

On my Virtual PC which had BizTalk 2013 R2 configured with SQL 2012 as database server I thought of installing SQL 2014 and try using the new features of Column Store and see how it can help run the Integrations faster.
In this post I will show you how I migrated my existing BizTalk databases from SQL 2012 to 2014 which is installed on the machine.


  •  Take Backup of all BizTalk databases from SQL 2012 and Restore it on to SQL 2014.
  •  Create Scripts of all BizTalk SQL Jobs from SQL 2012 and execute it on to SQL 2014.
  •  Create Scripts of all BizTalk SQL Logins from SQL 2012 and execute it on to SQL 2014.
  •  Update the SampleUpdateInfo.xml file found in the following location with info of the current and the new SQL Server. For me current SQL 2012 was on KIWI server and the New SQL 2014 Server is on KIWI\SQL14.
    C:\Program Files (x86)\Microsoft BizTalk Server 2010\Bins32\Schema\Restore
  •  Run the UpdateDatabase.vbs file which is found in the same folder which updates the Server references in the tables on the new SQL Server.
  •  Run the UpdateRegistry.vbs file which is found in the same folder which updates the System Registry key references on the Server.
  •  Finally I went into BizTalk Admin Console to check if the references were updated successfully and yes it did update everything.

Finally I would give credit to the following old Microsoft document which still holds true for  the new versions of BizTalk\SQL Server ;).
How to Restore Your Databases



Wednesday, May 30, 2012

Database Lookup Functoid : Multiple Where Clause : CRM PickList field

When integrating CRM I came across a Scenario while mapping a PickList field in CRM using BizTalk. Since we need to send the Index (AttributeValue) of the Value in the Xml to CRM for the PickList field I had to do a look up first to get the Picklist value Index.
Assume my Query is
Select top 1 from StringMap where Value='Staff' and AttributeName='lucky_title'
Staff comes from the Title field in the Input Xml.

Now in traditional Database Lookup Functoid we know about single where clause parameters but what if we have a multiple where clause?
Here is the StringMap table in CRM 2011


In that case what we have to do is add a String Concatenate Functoid or a Scripting Functoid for the Multiple Column and Multiple Value parameter with a separator.
I have used a Scripting Functoid.
select top 1 * from StringMap where Value + '|' +  AttributeName = Title|lucky_title






Tuesday, May 3, 2011

BAM Portal Activity Search: "This action cannot be performed because one or more database(s) appears corrupted"

Hi,
I noticed this error when I tried to search on an Activity in the BAM Portal.








I googled and noticed a good description about this issue by Gilles but it did not help me resolve the problem.

So I thought of fixing it in the BAM (BAMPrimaryImport)database as it clearly said about duplicate entry. I searched on the ActivityID and found only 1 record in "bam_ActivityName_active" table and I also found 1 record in the "bam_ActivityName_completed" Activity table.
SELECT * FROM [BAMPrimaryImport].dbo.bam_ActivityName_active where ActivityID='{42B99A00-4A43-40D4-8F6F-183851984197}'
So I thought that its not a duplicate issue as the Error says as I saw only 1 entry in each tables.
But I was wrong.

The issue is that there should not be any pending records in the Active tables if  the Activity is completed ie. if there exist a record in _Completed table for the same ActivityID.
In my case I intiated an Activity(BeginActivity) and Biztalk failed while updating the Actvity(UpdateActivity)and after that I completed the Activity(EndActivity). So there was an Orphan record in the _active table.
So I deleted all the records from _active table and it worked fine.
DELETE FROM [BAMPrimaryImport].dbo.bam_ActivityName_active

So this is what BizTalk means by Duplicate records.
"There should not be a record in the _active table if the activity has a record in the _completed table for the same ActivityID.If it exist then its a duplicate Error."

Error in Eventlog was as follows:
Event Type: Error
Event Source: BAM Portal
Description:
(BAMPortal.PortalApplication) Void LogAllErrors(System.Exception[]): System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.Web.Services.Protocols.SoapException: System.Web.Services.Protocols.SoapException: There are instances with duplicate ID '{42B99A00-4A43-40D4-8F6F-183851984197}' in activity 'xxx'. The duplicates must be removed from the database to fix this problem.
   at Microsoft.BizTalk.Bam.WebServices.Query.BamQueryService.GetInstanceData(String viewName, String activityName, InstanceQuery query, Int32 timeout)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Microsoft.BizTalk.Bam.WebServices.QueryService.BamQueryService.GetInstanceData(String viewName, String activityName, InstanceQuery query, Int32 timeout)
   at Microsoft.BizTalk.Bam.Portal.DataAccess.QueryResultsObjectDataSource.ExecuteQuery(SQLQuery query)
   at Microsoft.BizTalk.Bam.Portal.DataAccess.QueryResultsObjectDataSource.EnsureData(SQLQuery query)
   at Microsoft.BizTalk.Bam.Portal.DataAccess.QueryResultsObjectDataSource.QueryResults(SQLQuery query)
   at BAMPortal.Search_aspx.ExecuteQuery()
   at BAMPortal.Search_aspx.executeQueryButton_Click(Object sender, CommandEventArgs e)
   at System.Web.UI.WebControls.Button.OnCommand(CommandEventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   --- End of inner exception stack trace ---
   at System.Web.UI.Page.HandleError(Exception e)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at ASP.pages_search_aspx.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)



Happy Talking Biz. ;)

Thursday, January 17, 2008

Working with Biztalk Database


Count of all Orchestration instances grouped by state
 What it does:   Gives statistical information about all orchestration instances in your system and groups them into the different states they might be in. This type of information is available in the admin MMC by right clicking on an orchestration and selecting properties. This is just a way to rollup all data across all orchestration types and to do it programmatically.
How to read the results: If you have a large number of suspended instances well then something is failing. If you have a large number of dehydrated instances it could indicate a problem with your backend systems not responding promptly or it could just mean that the host in which messaging services are running is not up. If you have a large number of Ready To Run services then either your server is not up or you have a lot of load on your system and are trying hard to keep up. Might not be a problem if we catch up later, but if we can’t catch up then your system is being over driven.
What to do: If they are suspended, you need to look at the suspended info in HAT and determine why they are suspended and do something about. If they are dehydrated and you are concerned, you should look at the message flow to see what they are waiting for and then determine why that message has not come back. If they are ready to run, you should make sure your services are running and then check CPU utilization on these machines and other resource issues because they might be over-driven.
 SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SET DEADLOCK_PRIORITY LOW
 SELECT  o.nvcName AS Orchestration, COUNT(*) as Count,
                CASE i.nState
                                WHEN 1 THEN 'Ready To Run'
                                WHEN 2 THEN 'Active'
                                WHEN 4 THEN 'Suspended Resumable'
                                WHEN 8 THEN 'Dehydrated'
                                WHEN 16 THEN 'Completed With Discarded Messages'
                                WHEN 32 THEN 'Suspended Non-Resumable'
                END as State
FROM [BizTalkMsgboxDb]..[Instances] AS i WITH (NOLOCK)
JOIN [BizTalkMgmtDb]..[bts_Orchestration] AS o WITH (NOLOCK) ON i.uidServiceID = o.uidGUID
--WHERE dtCreated > '2004-08-24 00:00:00' AND dtCreated < '2004-08-24 13:30:00'
GROUP BY o.nvcName, i.nState

Counts for all host queues
What it does:   This will return the table size for the three queues described in the tables section for all applications
How to read the results: If the suspendedQ grows, things are failing. If the workQ grows, you are either over-driving the system, your services are off, or perhaps things have failed and you are going to do retries so the messages are delayed (see valid time). If the state queue grows, you either have a lot of dehydrated orchestrations, or you might be having problems with MSMQt.
What to do: If it is the SuspendedQ, use the error information in HAT and the eventlog to figure out what is failing and fix it. Make sure to either resume or terminate these instances eventually. You don’t want stuff sitting around forever. If it is the workQ, check to make sure the services are running. If they are, check to see if the CPU or other resources are pegged since you might be over driving the system. Also check the evenlog for warnings indicating transport failures which could cause retires. If it is the StateQ, check to see if you have a lot of dehydrated or suspended orchestrations and if so, why. You can also run one of the later queries to try and see if it is an MSMQt instance holding all the references and if so, you are probably not sending data to the outgoing queue anymore because we are still waiting for an ack for an earlier message.
 SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SET DEADLOCK_PRIORITY LOW
 CREATE TABLE #Temp (AppQueue nvarchar(256), QueueSize int)
declare @nvcAppName sysname
declare MyCursor CURSOR FAST_FORWARD FOR
SELECT nvcApplicationName FROM [BizTalkMsgboxDb]..[Applications] WITH (NOLOCK)
 open MyCursor
FETCH NEXT FROM MyCursor INTO @nvcAppName
WHILE (@@FETCH_STATUS = 0)
BEGIN
                INSERT INTO #Temp
                exec ('SELECT ''' + @nvcAppName + 'Q'', COUNT(*) FROM ' + @nvcAppName +'Q WITH (NOLOCK)')
                INSERT INTO #Temp
                exec ('SELECT ''' + @nvcAppName + 'Q_Suspended'', COUNT(*) FROM ' + @nvcAppName +'Q_Suspended WITH (NOLOCK)')
                INSERT INTO #Temp
                exec ('SELECT ''InstanceStateMessageReferences_' + @nvcAppName + ''', COUNT(*) FROM InstanceStateMessageReferences_' + @nvcAppName + '  WITH (NOLOCK)')
                    FETCH NEXT FROM MyCursor INTO @nvcAppName
END 
SELECT * FROM #Temp ORDER BY QueueSize DESC
 close MyCursor
deallocate MyCursor
DROP TABLE #Temp

 Count for number of state messages grouped by instances
What it does:   This will give you a count of the number of state messages associated with each instance
How to read the results: This specific query is probably only useful for systems which use MSMQt as a quick warning when things are starting to go wrong. If you have a lot of messages building up for a specific instance and that instance is an MSMQt instances, you could have problems.
What to do: If you have one of these problematic instances and the service class is MSMQt, you can look at the UserState column to determine what the name of the queue is which we are talking to and then you need to see why the communication with that machines queue is not working. If this is an orchestration, it is possible this is simply expected. It depends on your business logic as to why so many messages are going to the same instance.
 SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SET DEADLOCK_PRIORITY LOW
 CREATE TABLE #Temp (AppName nvarchar(256), StateMessages int, InstanceID uniqueidentifier, ServiceClassID uniqueidentifier, ServiceState nvarchar(256))
declare @nvcAppName sysname
declare MyCursor CURSOR FAST_FORWARD FOR
SELECT nvcApplicationName FROM [BizTalkMsgboxDb]..[Applications] WITH (NOLOCK)
open MyCursor
FETCH NEXT FROM MyCursor INTO @nvcAppName
WHILE (@@FETCH_STATUS = 0)
BEGIN
                INSERT INTO #Temp
                exec ('SELECT ''' + @nvcAppName + ''', COUNT(*), i.uidInstanceID, i.uidClassID, i.nvcUserState FROM InstanceStateMessageReferences_' + @nvcAppName + ' AS s WITH (NOLOCK) JOIN Instances AS i WITH (NOLOCK) ON s.uidInstanceID = i.uidInstanceID GROUP BY i.uidInstanceID, i.uidClassID, i.nvcUserState')
                    FETCH NEXT FROM MyCursor INTO @nvcAppName
END
SELECT * FROM #Temp ORDER BY StateMessages DESC
 close MyCursor
deallocate MyCursor
DROP TABLE #Temp

Count of all active messages for a specific sendport
What it does:   This query not only gives the count for how many messages are in the workQ for a given sendport, but it will do a breakdown based upon the primary and secondary transport also. Even better, it will give you a count for the maximum number of retries any message is on.
How to read the results: Having a high number for a certain transport is not necessarily worrying. It is basically the same as having a lot of data in the workQ generically and could just mean your system is slow. If you retry count is high it means things are failing. If you have a lot of messages on the secondary transport, then things never succeeded on the primary and now have failed over to the secondary transport
What to do: You should look in the eventlog for information on why the failures are happening and perhaps look into the system which this sendport is communicating with the to figure out what the problem is.
 SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SET DEADLOCK_PRIORITY LOW
 CREATE TABLE #Temp (MaxRetries int, Active int, SendPort nvarchar(256), IsPrimaryTransport int)
declare @nvcAppName sysname
declare MyCursor CURSOR FAST_FORWARD FOR
SELECT nvcApplicationName FROM [BizTalkMsgboxDb]..[Applications] WITH (NOLOCK)
open MyCursor
FETCH NEXT FROM MyCursor INTO @nvcAppName
WHILE (@@FETCH_STATUS = 0)
BEGIN
                INSERT INTO #Temp
                exec ('      SELECT    MAX(q.nRetryCount) AS MaxRetries
                                                  ,COUNT(*) AS Active
                                                  ,sp.nvcName AS SendHandlersHostServiceName
                                                  ,spt.bIsPrimary AS IsPrimaryTransport
                                FROM ' +  @nvcAppName + 'Q as q WITH (NOLOCK)
                                                  INNER LOOP JOIN Subscription as s WITH (NOLOCK) ON q.uidServiceID = s.uidServiceID AND s.uidPortID = q.uidPortID
                                                  INNER LOOP JOIN [BizTalkMgmtDb]..[bts_sendport] as sp WITH (NOLOCK) ON q.uidServiceID = sp.uidGUID
                                                  INNER LOOP JOIN [BizTalkMgmtDb]..[bts_sendport_transport] as spt WITH (NOLOCK) ON sp.nID = spt.nSendPortID AND spt.uidGUID = q.uidPortID
                                GROUP BY  sp.nvcName, s.uidPortID, spt.bIsPrimary
                                ORDER BY  SendHandlersHostServiceName ASC')

                FETCH NEXT FROM MyCursor INTO @nvcAppName
END 
SELECT * FROM #Temp ORDER BY Active DESC

close MyCursor
deallocate MyCursor
DROP TABLE #Temp

Last duration for our SQL Agent jobs
What it does:   This will give you a view into when each job last ran and how long it took. This is important to monitor not just because of the data it gives you but also to make sure you realize the importance of having sql agent running.
How to read the results: If the jobs start taking a long time, you could have database resource issues. Either you are running out of CPU or perhaps your disk is getting thrashed. If the job failed, it could be because of a number of deadlock issues which we are fixing in SP1 or have fixed in QFEs.
What to do: If it is a resource issue, you might need to consider beefing up your sql server. If the issue only happens rarely, then you are probably okay as we will catch up. If a failure occurred due to deadlock, you could consider getting SP1 if it has released yet as we fix a number of these issues. There is also a QFE out for deadlocking in the TrackedMessages_Copy job. In general, the deadlocks will not seriously hurt your system as long as they don’t occur too often. The job will fail and we will just have more work to do next time it kicks in.
 SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SET DEADLOCK_PRIORITY LOW
 CREATE TABLE #Temp (JobID uniqueidentifier,
                    JobName sysname,
                    Status int,
                    DateStarted int,
                    TimeStarted int,
                    Duration int,
                    OpEmailed nvarchar(20),
                    OpNetSent nvarchar(20),
                    OpPaged nvarchar(20),
                    Retries int,
                    Server nvarchar(30)
                    )
 CREATE TABLE #Final (MessageBox sysname,
                                    JobName sysname,
                                    DateStarted int,
                                    TimeStarted int,
                                    Duration int,
                    Status int
                    )

declare @dbName sysname
declare MyCursor cursor FAST_FORWARD FOR
select DBName FROM [BizTalkMgmtDb]..[adm_MessageBox] WITH (NOLOCK)
 open MyCursor
 FETCH NEXT FROM MyCursor INTO @dbName
WHILE (@@FETCH_STATUS = 0)
BEGIN
     INSERT INTO #Temp
    exec ('[msdb]..[sp_help_jobhistory] @job_name = ''MessageBox_DeadProcesses_Cleanup_' + @dbName + '''')
    INSERT INTO #Final
    SELECT TOP 1 @dbName, JobName, DateStarted, TimeStarted, Duration, Status FROM #Temp
    TRUNCATE TABLE #Temp  

    INSERT INTO #Temp
    exec ('[msdb]..[sp_help_jobhistory] @job_name = ''MessageBox_Message_Cleanup_' + @dbName + '''')
    INSERT INTO #Final
    SELECT TOP 1 @dbName, JobName, DateStarted, TimeStarted, Duration, Status FROM #Temp
    TRUNCATE TABLE #Temp  

    INSERT INTO #Temp
    exec ('[msdb]..[sp_help_jobhistory] @job_name = ''MessageBox_Parts_Cleanup_' + @dbName + '''')
    INSERT INTO #Final
    SELECT TOP 1 @dbName, JobName, DateStarted, TimeStarted, Duration, Status FROM #Temp
    TRUNCATE TABLE #Temp  

    INSERT INTO #Temp
    exec ('[msdb]..[sp_help_jobhistory] @job_name = ''PurgeSubscriptionsJob_' + @dbName + '''')
    INSERT INTO #Final
    SELECT TOP 1 @dbName, JobName, DateStarted, TimeStarted, Duration, Status FROM #Temp
    TRUNCATE TABLE #Temp  

    INSERT INTO #Temp
    exec ('[msdb]..[sp_help_jobhistory] @job_name = ''TrackedMessages_Copy_' + @dbName + '''')
    INSERT INTO #Final
    SELECT TOP 1 @dbName, JobName, DateStarted, TimeStarted, Duration, Status FROM #Temp
    TRUNCATE TABLE #Temp  
   FETCH NEXT FROM MyCursor INTO @dbName
END

SELECT * FROM #Final ORDER BY MessageBox
close MyCursor
deallocate MyCursor
 drop table #Temp
drop table #Final

Tuesday, November 22, 2005

Database Lookup Functiod[For Beginners only]


Working with BizTalk and don’t need to interact with SQL database…….nah…that’s not possible. I googled for database Lookup functiod but no link gave me a simple sample as to what this functiod does and other functiods which are linked to this Database Lookup Functiod. So I just thought to pen down few Standard database functiods available with BizTalk
First let’s start with.
Database lookup Functiod.
I created a table called “NishTable” with fields and values as below. DBFunctImage1
                                           Fig1

Then I create an Empty BizTalk Project with
1 Map and 2 Schemas.
Create the Schemas as shown in the Fig2.
Just drop in the Database Lookup Functiod on the Map as shown in Fig2.
DBFunctImage2
                                        Fig2

Let’s Configure this Database Lookup Functiod.
For this Sample I won’t pass any input …it would be harcoded.
Right click on the Functiod…properties…
1 parameter-Just type 2
2nd Parameter-Sql connection String.
3rd Parameter-Table name-NishTable (Created before)
4th Parameter-Column name.-EmpID
What these configured values means is
“Select _ from NishTable where EmpID=2”.See fig 3 for details.
DBFunctImage3
                                             Fig3
Now we need to fill in the blank space in the above sql query as to what should be selected. So we use value extractor functiod and configure it as soon in fig4.
EmpName is the field whose value I want…So I type “EmpName” as second parameter.
Mapping is simple 1 to 1 map.
DBFunctImage4
                                             Fig4
This way a Database Lookup functiod works. You can test your map.
Now what about error handling. If the sql connection is down?
So let’s use “Error Return functiod” here.
Just link the functiods as shown.
“Error Return functiod” requires only 1 parameter that should be the output of Database Lookup functiod.
Refer fig 5 for more details.
DBFunctImage5
                                          Fig 5
Just to test it I stopped my Sql server and I can see the output as below. DBFunctImage6
                                           Fig6
So this was Database lookup Functiod. We can use this instead of using a .net component inside map to get the values from database.