:: TheOneAndTheOnly.com - Andrew Buckman ::

So it seems there’s something wrong with Urchin 5 that is preventing my web stats from being compiled out of the logs files and into Urchin’s reporting interface. This began happening a year after I switched to the current server (running Plesk 7.5) and I noticed it on a few more important domains and found a fix at that time. Meanwhile I wrote myself a post-it note to go back and fix it on the rest of the domains, which of course I never did. Today I was curious about some stats for one of the domains I hadn’t fixed and thankfully was still able to find my note. I’ve decided to blog the solution so that I don’t have to worry about losing that note any longer and hopefully it will help someone else in the future as well.

If you try processing your log by clicking the “Run Now” button in Urchin Admin and see the following message come up, these instructions should help with your problem.
WARNING: (7063-54-63) Unable to open database for writing since it has been archived

The official solution to this problem exists on the Urchin Help site (now owned by google) at this location:
http://www.google.com/support/urchin45/bin/answer.py?answer=28527&topic=7393

My more detailed walkthrough follows…

The problem has to do with the archiving feature on a per domain basis. If you login to the Urchin Admin interface and configure the profile for that domain, there is a Storage/DB tab. On the tab you’ll see “Archive DB Options” with options for on/off and a timeframe for archiving if you leave it on. Change the setting for “Archive DB” to off and click “Update” to save your change.

The second half of the fix is a bit trickier and will require shell access to your server with an appropriate permissions level that grants you access to urchin’s installation directory. I logged in via ssh and switched to the superuser account to perform the following tasks (obviously you do so at your own risk, remember when you’re the superuser you have the power to break many things you don’t want to break). First, find where urchin is storing its reports for the domain you’re fixing (/usr/local/urchin/data/reports/theoneandtheonly.com/ for this domain). Change to that directory and look at the contents. You should see a variety of zip files named with the following format: YYYYMM-archive.zip. You should unzip these files to restore the data from the archives and remove the archive.zip files after they’ve been unzipped. This is important, you MUST remove the archive files, or at least move them to another directory so Urchin doesn’t see them.

UPDATE: By request, here is a list of the commands I ran for step 2…
cd /usr/local/urchin/data/reports/theoneandtheonly.com/
unzip *-archive.zip
mkdir archive-backup
mv *-archive.zip archive-backup


After both steps above are complete, go back to your Urchin Admin interface and run the stats report. You should see it processing your log files again and your missing data should fill in. Depending on the log file rotation schedule for your webserver you may or may not have gaps. If you keep backups on your server of all the logs, you should be able to reconfigure urchin to process the old files if you don’t have it setup that it does so already.

Since hink asked, here are my thoughts on the whole Google Sitemaps idea.

Overall, I love it. The ability to tell the search engines “hey, check this page out often and don’t bother with these over here but once a month” could prove quite useful. That said, part of me wonders if it isn’t just adding extra work for web developers that already have too much to do, though for a proper dynamic site a little work upfront to let the site generate the sitemap itself should mostly negate that. Even so, Google seems to do a pretty good job on their own without our input.

Then of course we all know that (the majority of?) sites will use the sitemaps completely improperly. Does anyone want to bet how many “webmasters” will setup a Google Sitemap telling them to check every single page, every day, with all pages at a priority of 1.0 because everything on my site is important! The concept of ‘relative to other pages on the same site’ will escape them and while they’re only hurting themselves with that, I feel for anyone having to explain to a client why a particular page on their site was only assigned a 0.3 priority let alone 0.1.

In the end I expect it will stick around, Google will ignore a good portion of them due to improper setup, and those with well designed sitemaps will benefit. Which I like to think is a good thing.

Google recently released their new Google Sitemaps as a beta (what do you expect from google?), here a few links I’ve been reading on the subject.

Google Sitemaps Homepage

Google Sitemap Protocol

Google Sitemaps Overview from Search Engine Watch

Breaking Down Google Sitemaps XML from Social Patterns

Google Sitemap for Wordpress Blogs also from Social Patterns

Just came across this interesting new take on graphing.
Sparkline PHP Graphing Library (http://sparkline.org/)

Sparklines are “intense, simple, wordlike graphics” so named by Edward Tufte.

Personally I rather like the idea of integrating small word-sized graphs in documents, certainly would have fit in on the basic web stats overview I had in the midwestgallery.com’s user area.