Suddenly , We are receiving an Disk space alerts from Production BizTalk 2010 database server . Alerts are set if 90% of disk space is full . I have not noticed any slowness in BizTalk data processing till now . Below are points I have noticed :
BizTalkDTADb size is ~ 65 GB ( Data file ~ 55 GB + log file ~ 10GB ) . All other database sizes are < 2 GB .
SQL Agent Job for purging and archiving DTA DB is not configured .
BizTalk is running more than 3 years now.
Global Tracking is on from Day 1 .
I can see orchestration Track Events checked in for orchestration tracking and can not find port level tracking checked in .
Below are the action items i have planned till now based on my internet searches :
Full Back up of BizTalk databases .
Take BizTalk offline
Purge BizTalkDTADb (As we do not have any usage of tracking data) using Terminator Tool .
Take BizTalk online again .
I have below questions :
I will be doing this for the first time , Could you please validate if I am going towards right direction .
What is the difference between running stored procedure run from SQL agent Job (dtasp_BackupAndPurgeTrackingDatabase) and running terminator tool to purge DTA DB . Because I read online , that running SP(for full clean up ) might take days to execute because of current size . How much time should terminator tool take ?
I just installed Latest BizTalk terminator Tool v2.5.6.9 available over internet . But I unable to find "Purge Everything in DTA" option as explained in https://blogs.msdn.microsoft.com/amantaras/2014/04/29/purging-trackingdta-db-using-terminator-tool/ .
What option I should go for clean up of DTA DB ?
Please let me know if you need more information to answer .
Regards,
Goutamendu
I would rather do the following:
Ask to add more disk space immediately to stop alerts and to allow yr prod environment to run smoothly without interruption.
Turn off global tracking from BizTalk admin console and restart host instances
Configure the purge job and let it cleanup. You can repeatedly configure it to reduce by few days at a time until u come down to where u want
You may still need to have DBAs shrink data files to reduce size of file
With this approach your environment will keep running and u be able to reduce DTA db size on the background. terminator tool you should only use if that’s the only resort.
Do not use the Terminator tool.
It would work, but it's for more extreme circumstances. Since all you're seeing is a Warning after ~7 years, you can probably take youy time.
Assuming all other Agent Jogs are running without error, including Backup BizTalk Server:
Double check with anyone, including Developers, that the Tracking data is not necessary for anything. If it is not...
During a regular downtime, manually backup all the databases by running sp_ForceFullBackup (Mgmt DB), then running the Backup BizTalk Server Job.
Run dtasp_PurgeAllCompletedTrackingData (DTA DB).
Configure DTA Purge and Archive and enable.
Depending on the size of the tracking database, the purge might take some time.
Related
We are migrating from the Magento community to Magento cloud for one of our projects and we need to access DB for our custom developed CRM.
But unfortunately magento cloud does not support DB replication and they have enabled binlogs and they are not supporting for creating replication user and server id setup, The binlog files can be synced to our CRM server periodically.
Now we want to know whether we can use the binlog files to replicate the database or is there any workaround for doing the same?
We have tried using tunnel setup but the query execution time is more while using tunnel setup which will affect our CRM performance badly.
Also we need to reconfirm whether there are any other possibilities we can try to access the Magento Cloud DB in our CRM without performance lag.
Thanks in advance for your suggestions.
Yes, it is possible, but it may be a little fiddly in the setup you are describing. You can replay the binlogs as relay logs. Have a look at this article for more details:
https://lefred.be/content/howto-make-mysql-point-in-time-recovery-faster/
Specifically, these parts are relevant (you'll need to edit them appropriately):
[root#mysql1 mysql]# for i in $(ls /tmp/binlogs/*.0*)
do
ext=$(echo $i | cut -d'.' -f2);
cp $i mysql1-relay-bin.$ext;
done
[root#mysql1 mysql]# ls ./mysql1-relay-bin.0* >mysql1-relay-bin.index
I use asp.net mvc, sql server. Query in my repository's class. Sometimes query is executed in 10 seconds, sometimes in 3 minutes!! Why? I used a SQL Server Profiler, but I realy don't understand what could be the cause and how I can find it.
Query:
SELECT
[Extent1].[Id] AS [Id],
[Extent1].[FirstAddressId] AS [FirstAddressId],
[Extent1].[SecondAddressId] AS [SecondAddressId],
[Extent1].[Distance] AS [Distance],
[Extent1].[JsonRoute] AS [JsonRoute]
FROM [dbo].[AddressXAddressDistances] AS [Extent1]
Check your query plan. Just run your SELECT statement in SqlServer Management Studio to obtain real query plan. More info is here: Query plan.
If they are the same, but response time differs significantly between the calls, than probably the issue is with lockc on db level (or huge active workloads). I mean incorrect transaction isolation level for instance or some reports running in the meantime obtaining too much resources (or generating locks "because of something" to ensure some data consistency enforced by some developer).
Many factors have influence on performance (including memory available at the moment of query execution).
You can run also a few queries to analyze quality of your statistics (or just update all of them using EXEC sp_updatestats) or please analyze fragmentation of the indexes. I guess, but by me locks and outdated stats or defragmented indexes, can force SqlServer to choose very inefficient query plan.
Some info on active locks: Active locks on table
Additional info 1:
If you are the only user of this db and it's on your local machine (you use SQLServer Express) the issue with locks is rather less possible then other problems. Try to open Event Log of SqlServer. It's available in SqlServer Management Studio on left side (tree) under your engine instance here: Management/Sql Server Logs/Current. Do you see any unusual info there? Try to review system log also (using Event Viewer app). In case of hardware problems you should see there also some info. Btw: how many rows do your have in the table? Try to review also behavior of your disks in some Process Explorer or Performance Monitor. If disk queue length is to big it can be main source of the problem (in such case look what apps stress disk)...
More info on locks:
SELECT
[spid] = session_Id
, ecid
, [blockedBy] = blocking_session_id
, [database] = DB_NAME(sp.dbid)
, [user] = nt_username
, [status] = er.status
, [wait] = wait_type
, [current stmt] =
SUBSTRING (
qt.text,
er.statement_start_offset/2,
(CASE
WHEN er.statement_end_offset = -1 THEN DATALENGTH(qt.text)
ELSE er.statement_end_offset
END - er.statement_start_offset)/2)
,[current batch] = qt.text
, reads
, logical_reads
, cpu
, [time elapsed (ms)] = DATEDIFF(mi, start_time,getdate())
, program = program_name
, hostname
--, nt_domain
, start_time
, qt.objectid
FROM sys.dm_exec_requests er
INNER JOIN sys.sysprocesses sp ON er.session_id = sp.spid
CROSS APPLY sys.dm_exec_sql_text(er.sql_handle)as qt
WHERE session_Id > 50 -- Ignore system spids.
AND session_Id NOT IN (##SPID) -- Ignore this current statement.
ORDER BY 1, 2
GO
Before you waste any more time on this, you should realize that something like the time a query takes in development is essentially meaningless. In development, you're running a single-threaded web server in IIS Express, which means that you've also got VS running, sitting on roughly 2-4 GB of RAM. Together with that, you're running a SQL Server instance, that's fighting the system for both RAM and hard drive time. You haven't given any specs of your system, but if you also happen to be sporting a consumer-class 5400 or 7200 RPM platter-style drive rather than an SSD, that's going to severely impact performance as well. Then, we haven't even got into what else might be running on this system. Photoshop? Outlook? Your favorite playlists of MP3s decoding in the background? What's Windows doing? It might be downloading/applying updates, indexing your drive for search, etc. None of that applies any more when you move into production (or at least shouldn't). In production, you should have a dedicated server with 4-8 GB of RAM and an SSD or enterprise-class 15,000+ RPM platter drive devoted just to SQL Server, so it can spit out query results at lightning speeds.
Long and short, if you want to guage website/query performance of your application, you need to deploy it to a facsimile of what you'll be running in production. There, you can pound the hell out of it and get some real data you can actually do something with. Trying to profile your app in development is just a total waste of time.
I have an old database - a users membership/role that was setup automatically by an ASP.Net 2 application years ago:
The Sql Server version currently running is: Sql Server 10.5.1617
The users database log file is huge (the ldf file is approx 400 times the size of the mdf file).
The recovery model is currently set to "Full". I understand what that is - and I don't need point in time restoration.
If I simply changed the recovery model to "Simple" from within Sql Server Management Studio:
...and clicked ok to save the changes - would I be risking my current database in any way? Or is Sql Server fine with making changes like this to live databases? And would the log file automatically shrink itself?
Thanks for your advice,
Mark
You should be fine, the transactions have been commited. The log file is waiting to be backed up and therefor released. Changing to Simple Recovery means that you cannot do rolling backups, but data will be commited to the db in the same way as before, logs are simply deleted after sql has completed writing the transaction.
To answer both of your questions:
Changing the recovery model on a live database is safe. You shouldn't incur any downtime, blocking, etc.
The log file won't shrink itself. You may find that once you've set the recovery model to simple that it may not be shrinkable right away. If you find that you're unable to shrink it, take a look at dbcc loginfo, specifically the 'status' column. Each row in the output of that command represents one virtual log file (vlf). The shrink command will only be able to clear a contiguous block of inactive (i.e. status = 0) vlfs at the end of the file. TL;DR - If you've got rows with status = 2 at the bottom, wait until you don't and then shrink.
Currently I'm working on a project with opends. I have to upload more than 200k entries in the OpenDS. But unfortunately its fails at random times when file limit exceeding more than 10k - 15k.
When I google for that particular error (alert ID 9896233: JE Database Environment corresponding to backend id userRoot is corrupt. Restart the Directory Server to reopen the Environment) it seems like openDS backend DB [BerklyDB] is not that reliable when adding massive number of entries. How can i plug in new commercial or open source reliable relational DB [Oracle/ H2] to the openDS. any configuration ? or do i have to change the openDS code ?
First you should be aware that Oracle has pulled the plug on the OpenDS project and it is now completely stalled. Development continues as open source as the OpenDJ project : http://opendj.forgerock.org.
This said, I believe that there is a problem with your environment. When I was still working on OpenDS, our basic stress test was importing and running very high load against 10 Millions users. 200K entries is not massive number. My daily OpenDJ tests on my laptop are done with 100K to 1M entries. We have customers running in production with OpenDJ with more than 20M entries, growing 40% every 6 months !
Berkeley DB has been proved to be very scalable and reliable.
Things you might want to check : what is the maximum number of files that can be opened by a single process on your machine ? Linux defaults to 1024 and the limit may be easy to hit with OpenDS or OpenDJ. Are you using a local filesystem ? Berkeley DB is not supported on networked FS such as NFS or other NAS.
Finally, check the logs/errors file and your systems log. Chances are that one of them will have a message containing the root cause of the problem (most likely logs/errors).
Kind regards,
Ludovic Poitou
ForgeRock - Product Manager for OpenDJ
I am running a BizTalk 2006 server instance on a SQL 2000 SP4 Database. I have a 10 GB Tracking DDB (9GB Used / 1GB Free). I am running the DTADB Archive & Purge jobs every hour. It is purging messages at 10 Days / 14 Days Hard. It runs without error. I take the purging down to 5 Days / 9 Days Hard and the Tracking Database's size only decreases by less than 5%.
Anybody have any thoughts or experience on what my be causing this issue?
I think it could be due to you using SQL server 2000.
The documentation for configuring purging of the database specifically states SQL Server 2005 and 2008.
http://msdn.microsoft.com/en-us/library/aa558715(BTS.10).aspx
There are also people who have had problems running purge scripts on SQL Server 2000.
http://www.biztalkgurus.com/forums/p/9443/18513.aspx
Hope this helps
By default, the tracking database** won't reduce in size - I suspect that if you look at the data and log file usage, you will find a large percentage in the unallocated (data file) and unused (log file) states.
You will need to shrink the database or individual files to reduce the overall database size using the DBCC SHRINKFILE command as discussed at Shrinking the Transaction Log in SQL Server 2000 with DBCC SHRINKFILE.
Hope this helps.
** or any database for that matter, unless the AUTO SHRINK option is enabled, however this isn't recommended: SQL Server Storage Engine Blog - Turn AUTO_SHRINK off!!
In the end, the only solution was to manually purge the tracking DB...
http://msdn.microsoft.com/en-us/library/dd800104(BTS.10).aspx
Not sure why it happens.
The DTA Archive and Purge SQL Server Agent job reduces the need to manually purge data from the BizTalk Tracking (BizTalkDTADb) database due to continuous purging of the database and compaction of stored tracking data. You might need to manually purge data if your BizTalk Tracking (BizTalkDTADb) database has grown so much that sustained performance degradation is occurring and the DTA Archive and Purge job is unable to keep up with the database growth.
Seems to imply this may be part of routine housekeeping.