Tuesday, March 27, 2012

Salesforce Data Tools

Here's a list of tools when working with Salesforce data, ie importing/exporting data
http://ezrakenigsberg.com/

Here's a few tools for dealing with 15 to 18 digits salesforce IDs
https://docs.google.com/spreadsheet/ccc?pli=1&key=0Ar3Bg2QuV-_IdEtzSXBrWTZiNUZxRlRoV0tYM3RoZ2c&hl=en#gid=0

Choosing the Appropriate Raid Level for Your Need

Here's an article that will help you choose a Raid level that's suitable for your needs.
http://www.techrepublic.com/blog/datacenter/choose-a-raid-level-that-works-for-you/3237

For large SATA drives, consider Raid 6 or 10 to avoid losing a lot of data.  However, Raid 5 has better performance.

Another solution is Raid 5 with synchronise mirroring

Things to consider includes:
Costs/Capacity Available
Read/Write Performance
Redundancy/Availability



Choose a RAID level that works for you

Takeaway: When choosing a RAID level for a new array, there are a number of important points that you need to take into consideration. Scott Lowe outlines these points.
In four recent TechRepublic blogs, we extolled the good and the bad about various RAID levels. From me, you learned about why I really like RAID 50 in a number of circumstances, why RAID 60 may or may not be overkill, and why RAID 10 might be a better choice than RAID 6 even though it’s more expensive. My fellow TechRepublic contributor Rick Vanover shared some pointers on when to choose RAID 5 and when to choose RAID 6.

RAID level considerations

When choosing a RAID level for a new array, there are a number of important points that you need to take into consideration, including:
  • Application performance needs. Not every application is created equal. Some applications are light on I/O needs, while others thrash the storage system all day long. Make sure you choose a RAID level that matches the workload.
  • Capacity needs. Different RAID levels all result in different amounts of net usable space remaining after accounting for RAID overhead. If capacity is your primary driver, that will affect your choice of RAID.
  • Cost. Performance costs money, and capacity costs money — achieving the necessary balance between cost and performance is your job. Choosing the right RAID level can play a big part in achieving this balance.
  • Availability needs. Every business is different. Perhaps your business is willing to pay a little more to ensure less downtime than another business. In these cases, you need to pick a RAID level that matches the system’s availability needs demanded by your organization.

The balance

Let’s look at each of these considerations and consider how various RAID levels meet the objectives for each point raised. We’re going to stick with relatively common RAID levels.
You’ll notice that I placed an asterisk next to two entries in each category below; the asterisks denote the “winners” in each category. You’ll also notice that RAID 0 “wins” a lot; however, I would never recommend RAID 0 for production use.
Application performance
  • * RAID 0. From a performance perspective, RAID 0 beats the rest since there is no RAID overhead, and the disk system is able to aggregate all of the disks into a single, high performance storage pool.
  • * RAID 1/10. In most cases, RAID 10 provides excellent performance since data can be read from multiple disks at the same time, suffering a little only when the workload calls for a whole lot of small sequential writes. For general raw performance for pretty much any kind of workload, RAID 1 and 10 are excellent choices. RAID 1 by itself is a two disk system that doesn’t get a huge performance boost, but it wouldn’t likely be used in a large array, anyway.
  • RAID 5/50. For heavy read workloads, RAID 5/50 provide very good performance. However, on heavy write workloads, RAID 5/50’s need to write parity information begins to noticeably affect overall storage performance. In a rebuild situation, RAID 5/50 can suffer a heavy performance hit until the rebuild operation completes.
  • RAID 6/60. Like other RAID levels, read performance under RAID 6 is very good, but write performance takes an even bigger hit than it does with RAID 5 due to dual parity write needs. Rebuild operations can have a major performance impact.
Capacity
  • * RAID 0. Since no parity information is stored and there is no mirroring, RAID 0 provides excellent capacity. You get full use of all of the disks in the array — 100% utilization.
  • RAID 1/10. With RAID 1/10, you take a full 50% capacity hit due to the need to retain a mirrored copy of the data. RAID 1/10 carry the largest capacity penalty, but this is often offset by its very good read/write performance.
  • * RAID 5/50. One reason RAID 5 remains so popular is because of its capacity overhead, which results in the loss of only one disk worth of capacity. Under RAID 5/50, you will lose up to 33% of total raw capacity (three disk RAID 5 configuration), depending on how you create your volumes.
  • RAID 6/60. RAID 6 is growing in popularity, but it carries greater capacity overhead than RAID 5. With RAID 6, two disks worth of space is required for parity, so you take a capacity hit of up to 50% (four disk RAID 6 configuration).
Cost
  • * RAID 0. From a capacity and a performance standpoint, RAID 0 carries by far the lowest price tag. With no RAID overhead and maximized performance, the $/TB or $/IOPS metrics are fantastic under RAID 0.
  • RAID 1/10. From a capacity perspective, RAID 1/10 carries a hefty cost, but from a performance perspective, it’s only a little worse than RAID 0. Although you lose 50% of your usable space under RAID 1/10, you retain high performance levels, making this RAID level very popular for a variety of uses.
  • * RAID 5/50. RAID 5/50 has become an almost de facto standard when one needs to add RAID and doesn’t really care about the characteristics. All RAID controllers support RAID 5, and the RAID 5 capacity overhead isn’t too bad, especially as more disks are added to the array. From a performance perspective, you do lose a lot of IOPS on write workloads, making RAID 5 a bit more expensive than RAID 0, 1, and 10 when it comes to supporting write workloads.
  • RAID 6/60. Expensive in every way, RAID 6 can result in capacity overhead matching RAID 1/10 (50%), and it also carries a hefty write penalty — it’s even worse than RAID 6.
Availability
  • RAID 0. On the availability front, RAID “zero” lives up to its name. It shouldn’t even be called RAID; it’s really just a bunch of disks (JBOD). If any disk in the array fails, you can kiss your data goodbye. Although RAID 0 provides great performance and maximum capacity, it includes zero data protection capability.
  • * RAID 1/10. RAID 1/10 - mirroring - is a highly available configuration. All data are written to two disks in the array, so you can lose multiple disks — as long as you lose the “right” ones — and remain functional on a single copy of the data.
  • RAID 5/50. RAID 5 provides reasonable availability and is often enough for many organizations. With RAID 5, your array can lose a single disk and remain functional, although in a degraded state. If you lose a second disk, your data is gone. RAID 50 provides a little more protection. Each individual RAID 5 subarray in the RAID 50 can lose a single disk and remain functional. In theory, you could lose a single disk in each and every subarray and remain functional.
  • * RAID 6/60. RAID 6/60 provide very high levels of availability since you can lose two disks in each RAID 6 array and remain functional.

My take

If you really don’t know what RAID level to choose, go with RAID 50 if capacity is more important than performance (unless you’re talking mostly sequential reads, in which case RAID 50 is awesome) or RAID 10 if both random and sequential read/write performance trumps capacity. If data protection is your primary concern, RAID 6/60 should be at the top of your list.

Sunday, March 11, 2012

Getting Salesforce Data from External App

Salesforce encourages developers to authenticate using OAuth.

However, if you are creating a windows service to get data from SF, you'll need to choose the username/password flow.
https://ap1.salesforce.com/help/doc/en/remoteaccess_oauth_username_password_flow.htm

The Steps include:
1) Add new application via Setup -> Develop -> Remote Access
Under this method, the callback URL will not be used.

2) Perform a POST request
To get the authentication token:


https://login.salesforce.com/services/oauth2/token?grant_type=password&client_id=3MVG9lKcPoNINVBIPJjdw1J9LLM82Hn
FVVX19KY1uA5mu0QqEWhqKpoW3svG3XHrXDiCQjK1mdgAvhCscA9GE&client_secret=1955279925675241571&username=username@salesforceInstance.com&password=SFpassword

3) Parse return JSON and get access_token

{"id":"https://login.salesforce.com/id/00Dx0000000BV7z/005x00000012Q9P",
"issued_at":"1278448832702","instance_url":"https://na1.salesforce.com",
"signature":"0CmxinZir53Yex7nE0TD+zMpvIWYGb/bdJh6XfOH6EQ=","access_token":
"00Dx0000000BV7z!AR8AQAxo9UfVkh8AlV0Gomt9Czx9LjHnSSpwBMmbRcgKFmxOtvxjTrKW1
9ye6PE3Ds1eQz3z8jr3W7_VbWmEu4Q8TVGSTHxs"}

4) Perform a GET request

https://ap1.salesforce.com/services/data/v20.0/sobjects/Account/0019000000B8JxR?fields=AccountNumber,BillingPostalCode

User-Agent: Fiddler
Authorization: OAuth  access_token
Host: ap1.salesforce.com