Keeping Your ERP Server Files Fit — Part II

When someone asks us, “How do you stay so fit?” we might talk about our diet and exercise regimen. The news is full of what to eat, what to avoid, and how much exercise we need. We thrive on these snippets, but the moiling reality is that to make a difference, we have to be consistent versus doing “yo-yo” dieting to maintain health.

In part one of this article, I talked about how to use server redundancy to keep your company healthy, wealthy and wise. To help your servers respond instantly, some consistent “nutrition and exercise” is also required. In part two of this article, we’ll explore “nutrition and exercise” tips for keeping a database server “healthy”: Organizing, Balancing, Archiving, and Participating.

Organizing
Have you ever emptied a full closet, re-organized everything, and then put it all back, to happily discover that your things are easier to find, and the closet now seems half-empty? Windows Server and SQL Server both have utilities to do this, and the more frequently these utilities are used, the more organized the data is on a regular basis.

Windows includes a utility called “Disk Defragmenter.” This utility finds pieces of data stored separately but go together, and moves them so they are stored together. This is a typical problem in a supermarket when you don’t have many big open places to put a new SKU. First you might need to slide other SKUs down to consolidate free space, or move some items to a new aisle all together. By doing this, it will be easier for everyone to find this SKU than if it were stored in three or four separate places just because it did not all fit in one place.

The good news is that just about any Windows system lets you schedule the Defragmenter to re-organize your data (a typical frequency for this is weekly). The bad news is that on a SQL Server, this job will not re-organize the files that matter most: the SQL Data files and log files that are locked for update whenever SQL Server is up and running.

Therefore, on SQL Servers, we need to make sure the system is organized before we install and build the SQL database. We need to pre-grow the database to its expected size. Lastly, we set the database to grow in bigger leaps. All of this keeps the database from growing too frequently in tiny pieces, since these tend to scatter all around, making it take longer for the computer to find things quickly.

Balancing
When a tree needs to get water from the roots up to every leaf, it’s faster if the tree has main branches, smaller branches and then twigs reaching the leaves. On the other hand, a very long “vine” has to carry the water an awful long way to water the furthest leaves down at the end. This is the problem with SQL databases too.

As you add more and more customers, inventory, orders, or other data to the database, it tends to build “vines” rather than a “balanced tree,” and so you’ll start to get delays when you are doing lookups. SQL Server comes with several utilities that should be used on a regular basis. These utilities re-organize these long vines into balanced trees. This is called “Index Rebuilding.” If you never ran this utility, your database server would still function, but responses might get very slow over time.

SQL Server helps you set up and schedule these utilities by providing a tool called the “Maintenance Plan Wizard” that can be used to do your balancing. This can also cause problems when your database is too out of balance, because the Wizard tries to process the entire database. There may not be time to do that overnight, causing extra locking delays the following morning. When you’re signed up for Morse Data’s SQL Server Health Monitoring Service, we take this a step further by monitoring which parts of the database need the most attention and tune these areas most frequently — allowing the maximum amount of balancing you can get.

Archiving
If you continuously add new inventory, customers, orders, and other data to your database every day, your database will grow every day. This means you are slowly increasing the work that the computer needs to do to find something and the amount of extraneous data that might be listed when you are looking for something. Additionally, it increases the work the computer needs to do when you are re-organizing or balancing your database.

To keep your system fit, it makes sense to regularly archive any old data that you don’t need anymore. I use the term “archiving” to mean that you might run a report, or make a full database backup, and then purge off the old data. This way you can save that report or backup copy for a fixed period of time in case you ever need to refer to it. The assumption is that this data is old enough that you probably won’t need it anymore.

For credit card-related data, the PCI requirement 3.1 doesn’t provide specific lengths of time that this data should or should not be stored, but it does state you must establish some sort of retention policy and then follow it. It makes sense to set this policy for all types of data you’re storing, and then set up this schedule on the server to follow this policy.

Participating
Microsoft and Morse Data are both constantly finding new ways to improve their software, and developing fixes as problems are reported. By participating and applying these service packs and updated versions regularly, we’re able to take advantage of the best possible operating environment for our organizations when it matters the most.

Is it better to skip or delay these updates and keep going happy just the way you are? I agree that upgrades can sometimes be painful, but delaying them for too long only builds them up and ultimately causes greater pain.

Did you like these two posts on how to keep your SQL server in tip top shape? If so

Share on FacebookShare on LinkedInTweet about this on TwitterShare on Google+Email this to someone

Server Redundancy Keeps Your Company Healthy, Wealthy and Wise

Benjamin Franklin coined the phrase, “Healthy and Wealthy and Wise.” We all want this, especially health because without health, the other two don’t matter as much.

When we’re healthy, we tend to forget how miserable we felt the last time we had a problem. It feels so great to be healthy, that once we overcome a problem, we eagerly shift focus to “Wealthy and Wise.”

This same human nature applies to how we take care of our computers.

It feels great when all systems are humming and the computers are responding instantly. In today’s world, this is a given. How frustrating is it, as a customer, to enter a web order with long delays between pages, or hear a CSR say, “Our computers are slow today?” Delays should be unacceptable, “downtime” is catastrophic, and just the thought of losing any data is unthinkable.

How do we keep our systems as consistently “Healthy” as possible, so that our business can focus on its goals?

First, servers need to stay humming

I.T. started making servers more reliable by doubling up the weakest point of failure. Disk drives are like incandescent light bulbs; they eventually burn out. These days,we set them up in groups called “RAID arrays.”

On a SQL Server, the data should be stored on a RAID 10 array, similar to the groups of tires on an eighteen wheeler. This distributes the weight, and the truck can keep going if one of the tires blows (to be replaced it as soon as possible).

Another way to increase server reliability is to mix disks from different manufacturers or different lot numbers. If one disk has a design flaw, they don’t all burn out at once. The “claimed” average life of a disk drive used to be 12 years, and now they are claiming as much as 57 years for consumer drives and 171 years for server grade drives. In real life, drives can last 15 minutes to 15 years.

In every 10 servers that are several years old, you may typically find one or two servers that have a failed drive in a group that needs to be replaced. The server is still functioning so often nobody is even monitoring for this.

In an important server with many drives, it’s a good idea to add an extra drive as a true “hot spare” that sits in waiting 24x7x365, and then automatically joins whatever group has a failure.

Think about it: your system is replacing the flat tire without even stopping the truck! Most servers can do this today, if you plan ahead and set it up this way. If they’re big enough, you can even use retired drives for this.

Second: Double up the entire server

If any other components on the server fail, another server can take over. Obviously now, instead of doubling the cost of your disk drives, you need to also double the cost of the entire server, and do additional set up so that the second server always has a fresh copy of what is on the first server.

For Web Servers and Terminal Servers, Windows comes with the ability to set up Server groups that can work together to “share the load.” If one fails, the others in the group need to work harder but they can keep things going.

Amazingly, SQL Server 2008 comes with this capability, and SQL Server 2012 improves it further to allow what they call “SQL Server Always-On Availability Groups.”

Picture a convoy of trucks. If one breaks down, they cast it aside and the next one instantly takes the load and continues the journey.

With some advance setup work from Morse Data, your InOrder application can enjoy this protection — that is, to jump to another server without anyone realizing that the main server just went up in smoke and triggered the sprinkler system.

Speaking of sprinkler systems, someone recently asked, “Why do I need still need to do backups and pay extra for disk drive groups, and now also extra servers!?”

The answer is clear if you think about it: Why do we have fire extinguishers when we have a sprinkler system? And why do we need sprinkler systems when we have fire departments and fire insurance?

Whether you’re hosting servers or running servers in house, you still need to ask your I.T. people what the plan is to keep your servers humming.

To keep our companies — and customers happy — we need all systems humming. However, we also need them to instantly respond — which will be Part II of this series.

Share on FacebookShare on LinkedInTweet about this on TwitterShare on Google+Email this to someone

Five Reasons to Keep Your Order Processing Credit Card Numbers In-House

To help protect consumers’ sensitive data, including credit card numbers, the Payment Card Industry Security Standards Council (PCI SSC) has been ratcheting up compliance regulations.

Regulations state that all credit card data must be protected. Complex and costly, these regulations have become a real burden to small and mid-sized businesses.

To help businesses minimize the amount of data kept on hand, and thus minimize the burden of meeting regulations, a new data security technology was developed. “Tokenization” replaces a piece of sensitive data with a value that isn’t sensitive. Card holder data is then stored in a separate database or off-site in a secure facility.

Merchants cried for help when they were told to implement new security standards, and Card Processors answered this call with offers to take on the secure card storage burden for them.

Tokenization sounds like a cost effective way to solve a complex problem. However, for multi-channel merchants, off-site tokenization may not be the right solution. Why?

1. Lack of flexibility – As a multi-channel merchant, different channels and/or markets may require that you take advantage of offerings from different payment processers. Tokenization prevents you from doing this as you’re locked into one processor.

2. Data is no longer “physical” – Because tokenization is a “software as service” application, once you sign on, you’re locked in, and sometimes getting your data back in one piece can be difficult. And, if your vendor makes a change – or if tokenization technology changes – you’re stuck.

3. Lack of future security – Mergers and acquisitions happen between vendors, requiring you to change to another processor. What happens to your outsourced tokens?

4. Risk still a factor – Credit card numbers that simply “pass through” your website checkout screens still require you to answer the “SAQ-D” questionnaire, even if you don’t “store” the card numbers. Therefore, “SAQ-C” scope can only be achieved by using a processor’s hosted checkout page (similar to a native PayPal checkout call) that sends payment confirmation back to your website on behalf of the customer.

Additionally, tokenization will never solve the call center and retail risks of exposure when credit card numbers are entered or swiped into your system.

5. Can’t easily change processing vendors – With tokenization, you’re locked in to one processing vendor.

If you use a Payment Application Data Security Standard (PA DSS) certified software system such as InOrder, you can rest assured you’re keeping your data safe.

In addition, by keeping your order process credit card numbers in house, you can route your authorizations and captures for preferred card reorders, backorders, standing orders and continuity orders to a different payment processor any time you decide to change your processing vendor to get a better rate.

What’s your take on tokenization? Are you considering it? Why or why not? Leave your comments below.

Share on FacebookShare on LinkedInTweet about this on TwitterShare on Google+Email this to someone

Welcome to the Get InOrder Blog!

Enterprise Resource Planning (ERP) software is continually changing – especially as more business functions move online.  Choosing the right ERP software can be a tough process. Meeting the demands of today’s online consumer can be tougher still.

Our goal with this blog is to educate you about ERP software, with a focus on the Order Management side of ERP.  This blog talks about how you can put it to use in your business – whether you’re thinking about ERP or you’re an InOrder client.

We’ll be offering our own “from the trenches” insights about things from real-time inventory and shopping carts to m-commerce and more. We’ll also be posting quick tips you can put to use immediately to get more from your InOrder software.

Please take a minute to subscribe to our blog. You can also connect with us on LinkedIn – or even better – join our LinkedIn InOrder Group headed by VP of Sales Tony Marchese. (You can find the group by doing a quick search on LinkedIn for “InOrder”.)

You can also help us out by clicking the “Like” buttons when you see something of interest.  This lets us know the topics and success stories that you find most useful.  And if time permits, let us know which topics you’d like to see addressed here by leaving your comments below.

Share on FacebookShare on LinkedInTweet about this on TwitterShare on Google+Email this to someone

1 (888) 667-7332

Contact Us

Literature Downloads


Contact

Corporate Headquarters
Morse Data Corporation
16 Pierce Street
Dover, NH 03820
Toll Free: (888) 667-7332
Phone: (603) 742-2500
Fax: (603) 742-8178
Technical Offices
Morse Data Corporation
9661 W. 143rd St. Suite 200
Orland Park, IL 60462
Toll Free: (800) 860-9515
Phone: (708) 873-0010
Fax: (708) 873-9967

About