Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Performance and...Performance and...Performance issues after moving to a new serverPerformance issues after moving to a new server
Previous
 
Next
New Post
12/19/2014 1:29 PM
 

Hi, there. 

I'm a network admin (with some IIS background, but never touched DNN before) who recently was asked to move a DNN 6.2 installation to a new server.  (The old server was an ancient 2003 box that was starting to have hardware issues - the new one is a brand new 2012 R2 server, and I've set up SQL 2008 Express on it.)   I backed up the site files, backed up the database, restored on the new server, set the connection string and had to tinker a little with application pools before the site came up and we were able to log into it.

I moved on to other projects, but lately they've dragged me back to try to troubleshoot issues with the site.  The site is sometimes normal, sometimes slow, and very occasionally will not load at all (though I think it's just timing out), seemingly at random.  When users log in to edit the site the various tools are also randomly slow.  Inserting an image or document is essentially impossible, with the image/file manager tools almost always timing out when opened, or on the occasions when they do open usually the first time the user clicks into a subfolder it stalls and times out.

My first thought was that maybe running an upgrade might relink or clean up or fix settings on the new server.  As I dug deeper into the upgrade documentation I began getting uncomfortable with trying this without more general knowledge of the DNN product and backed off to do more basic research and look for a little assistance. 

One thing that's really got me puzzled is that there's a large (6 GB or so) SQL database file in the \dnn\app_data  (or something that looks like that, sorry) folder, and when I was trying to make a backup copy of the folders ahead of the upgrade, Windows told me that the SQL server process had it locked open.  Problem is, that's not the database which I restored onto this server - it's the wrong size and in the wrong location.  And it doesn't show up in SQL Management Studio at all.  I looked back on the old server, thinking maybe I'd pulled the wrong database across, but no - the database visible in SQL manager is the one in the SQL folders, but there's still a large MDF in the DNN folder.  Does DNN somehow use this SQL database without actually attaching it to the SQL server instance?  Or have things gotten colossally messed up on both the original server and my new server?

So I'm looking for some guidance - ideas for how to move forward with troubleshooting this specific situation of course, but also some more-basic reference material for the making DNN work right.  I've downloaded and browsed through the 6.2 and 7 manuals in the last day, but these seem to be oriented mostly towards the how-to-build-sites set of knowledge rather than how-to-make-it-work-right.  Even the install and upgrade guides I've found so far seem to be just a couple of paragraphs of copying DNN into place and making a SQL database.

Thank you for your time and (hopefully) help.

 
New Post
12/19/2014 5:38 PM
 
to identify the database, check the connection strings in Web.config file. if it contains "database.mdf", it is user instance db in /app_data folder.
if this has a size of 6 GB, cleanup is not properly executed. Truncate tables SiteLog, EventLog and ScheduleHistory would be the first step, maybe
recreating search index as well. Afterawards compact the database file and performance should be improved.

Cheers from Germany,
Sebastian Leupold (Microsoft MVP)

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
12/20/2014 8:01 AM
 
There are two ways to install DNN - one is using a MS SQL database stored within the MS SQL datastore - and the other - which gets used most often for demo purposes and quick tests is to use the database.mdf in app_data - its not needed at all as a rule.

Westa
 
New Post
12/23/2014 2:12 PM
 

Thanks for the reply.  Talking about connection strings got me looking back at that part of the setup again, and what I found in my web.config looks screwy.

 

<connectionStrings>
    <!-- Connection String for SQL Server 2005/2008 Express -->
    <add name="SiteSqlServer" connectionString="Data Source=.\SQLExpress;AttachDbFilename=|DataDirectory|Database.mdf;Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient" />
    <!-- Connection String for SQL Server 2005/2008 
    <add name="SiteSqlServer" connectionString="Server=(local);Database=DNN5;uid=xxxxxxxx;pwd=yyyyyyyy;" providerName="System.Data.SqlClient" /> -->
  </connectionStrings>
  <appSettings>
    <!-- Connection String for SQL Server 2005/2008 Express - kept for backwards compatability - legacy modules -->
    <add key="SiteSqlServer" value="Data Source=.\SQLExpress;AttachDbFilename=|DataDirectory|Database.mdf;Integrated Security=True;User Instance=True" />
    <!-- Connection String for SQL Server 2005/2008 - kept for backwards compatability - legacy modules
    <add key="SiteSqlServer" value="Server=(local);Database=DNN5;uid=xxxxxxxx;pwd=yyyyyyyy;" /> -->

 

This is essentially the same between my before-the-move backup and my live production files right now.  When I went through the move I was just looking for the database name I thought was there and didn't parse through all the lines, saw the correct info and closed it up.

...but if I'm reading it right now, this is actually specifying TWO connection strings for two separate databases, both the one that's visible in my SQL management and a sort of run-time attachment of the database.mdf in the data folder.  This would explain why there doesn't appear to be any real information in the tiny SQL folders database, though why the behavior of the overall system would have changed from the old server to the new one is a bit of a mystery.  Or are there two-database scenarios like this?

So - what I'm thinking is that I should ideally do is remove the conn string for the presumably blank database, move the database.mdf database to a safer location and attach that from the SQL console, and fix the connection string to point to it there.  (After which I can do the database cleanup tasks which you're suggesting.  It's definitely a much bigger file on the new server.)  Does that make sense?

And if you have any links for more-explicit how-tos on the database cleanup stuff, that would be useful as well.

Thanks again for your help.

 
New Post
12/30/2014 9:05 AM
 
this is the uncommented connection string: "Data Source=.\SQLExpress;AttachDbFilename=|DataDirectory|Database.mdf;Integrated Security=True;User Instance=True"
it means, you are using a user instance database, which should not be attached to the server in SQL Server Management Studio, otherwise you may encounter strange effects or the web server not being able to access the database. You may attach the database and use database name instead, which is easier to maintain, if you are having SSMS access to the server.

Cheers from Germany,
Sebastian Leupold (Microsoft MVP)

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
Previous
 
Next
HomeHomeUsing DNN Platf...Using DNN Platf...Performance and...Performance and...Performance issues after moving to a new serverPerformance issues after moving to a new server


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.

Content Layout

Subscribe to DNN Digest

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.  


Copyright 2017 by DNN Corp Terms of Use Privacy
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out