Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

Database administrators would be more overworked if it weren’t for the ONE principal that universally governs all database activities (regardless of software brand): ACID. I don’t usually worry about having the acronym memorized (most people don’t). But since ACID is key to everything that databases are and will be, understanding the base concepts is essential. If I didn’t understand ACID, I’d quite likely be out of a job since troubleshooting SQL problems would be … well, almost impossible without that knowledge.

ACID is all about transactions and has 4 components: Atomicity, Consistancy, Isolation, and Durability. (I always forget the word “Atomicity”. Who even coined that mouthful?)

Atomicity, the first concept, defines a transaction. The question asked is “What steps are required to complete this task?” Most SQL Server books use the bank example. Say I want to pay my phone bill through my bank’s online billpay service. I use the software to schedule the payment, the bank takes money out of my checking account, packages the money into an electronic “thing,” sends the money to the phone company, then marks the money as sent in the banks own records.

If the process fails during or after step 2 (the bank taking the money), I stand to lose my payment, still owe the bill, and even end up with overdraft fees on my account because the bank keeps taking money out of my account. Since the bank can’t bleed money, they need to ensure that if any part of that process fails, everything “rolls back” to its original status (the money gets put back into my account and the bill goes unpaid). So every step of this process, even though they are unique steps, are wrapped up in an imaginary bundle of “All or Nothing” process called a transaction.

Consistency, the second concept, means that the transaction does not violate integrity. All records must be in a consistent state. This is a little harder to grasp than Atomicity. Again, I revert to a common example, orphaned records. The database may have a customer table with customer names in it and a separate address table that houses addresses with a customer ID column. For consistency, no address table record should exist for a non-existant customer. If I delete customer ID 456 in the customer table, all address records using customer 456 should likewise be deleted. A money column should not contain the value “ABC” and a date column should not contain 150. A transaction should always adhere to any data rules (foreign keys, constraints, default values, nullability declarations, etc.).

And, FYI, it’s not ACID’s fault if the DBA doesn’t establish those rules. If I have an orphaned record in my database, it’s not because ACID failed. It’s because I failed to do my job properly.

Isolation, the third concept, refers to the ability to manipulate multiple transactions in a state separate from each other. If I have 5 friends reaching for the pizza box, the pizza box should not constrain them from grabbing their slices at the same time, nor should any of them jostle the others away from the box and prevent anyone else from getting a slice.

(Okay, maybe that’s a bad example. I know some jokers who would do exactly that. @=)

The point is, if I’m updating customer information in my database, it should not prevent another process from reading customer information for the website or even removing customer information – even the stuff I’m currently accessing! (Yes, that really does happen). Nor should any deletes prevent my ability to update the record being deleted. (And that too really happens, but that concept is an entirely different topic.)

Durability, the last of the concepts, is probably the most important one to my mind. What happens in Vegas, stays in Vegas, remember? Well, what happens in the database (and gets committed) – no matter what else is going on – should stay in the database regardless of server failures, filled up hard drives, and other various system problems. Of course, Durability doesn’t mean a damn thing if I’m not backing up my databases, but backups – or lack thereof – are another topic.

The key to Durability, BTW, is that the data needs to be committed. If it is uncommitted data, chances are failure will cause it to roll back. And if it doesn’t, there are other, bigger issues at hand. For one thing, having an uncommitted transaction laying around violates the first concept of ACID. For another, it’s just Not Supposed To Happen (or so I’ve been told).

I take the Titanic view of ACID. Yes, ACID is brilliant and 99.999% of the time functions perfectly, but just because it’s unsinkable doesn’t mean it can’t sink (fail) that other .001% of the time. My thought is that ACID is both hardware- and software-dependent. If the software / database engine coding gets screwed up, then there is the possibility of failure. Until I can prove that this can happen, though, these thoughts are just my silly little imaginings. In public I will toe the ACID NEVER FAILS line.

To reiterate my initial point, we don’t need to memorize the concept terms (Atomicity, Consistency, Isolation, and Duration) unless we’re going to a job interview. But we all need to recognize the term ACID when it comes up in conversation and be able to discuss it intelligently. ACID is so central to every single other database concept that not knowing it and not understanding it is just begging to be pink slipped. Or laughed at for making pizza references in a tech blog post. Hmmm. Pizza.

‘Scuse me. Homer and I have some lunch to track down.

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

In the last Shadowrun Sundays post, we discussed a basic overview of worldbuilding. I’ve often heard it said that Dungeons and Dragons was originally based on The Hobbit and The Lord of the Rings trilogy. These books included species like orcs, dwarves, elves, and hobbits (halflings in D&D), which inspired Gary Gygax.

Whether or not the Tolkien inspiration myth is true, we can still see the echoes of these books in the world and the technology. Looking at the armor and weapons available in the game, we can place the period between the 12th and 14th centuries C.E. Based on that, the rest of the gear is created to keep the feel of the same time period. And then we have the infamous Bag of Holding.

Personally, I think Gygax based this one off someone’s purse. @=)

Because this is a fantasy world, we don’t see a whole lot of science technology in this game. In the original game, there wasn’t anything steam- or electric-powered. There were certainly no computers. Gygax added (at some point) a form of artificer species called gnomes who did build technological gadgets, but that came in at a later edition. We do, however, see a lot of magic and magical gizmos that take the place of technology.

Magic has rules (like all magic or other powers in various games). It needs to have rules or it can’t be used effectively in the course of the game. In Gygax’s original vision, magic’s source is primarily religious. One has to worship something (usually a god, but sometimes being a tree-hugger works too) in order to obtain one’s spells and power, then pray each day to renew the spell-casting ability.

These are the things we need to think about when worldbuilding for our RPG. The rules of our power system–whether we have superpowers (like Champions / Heroes), magic, or psionic abilities–must be well established enough that the players know how to use them and combat them during the course of play. It’s not enough to know that my character has teleportation powers. I need to know if I can teleport other objects or other people, if I retain my clothes and backpack when I teleport, and if I can teleport into places I can’t see or don’t know. Without knowing these things, a player can run roughshod over the game master and the other players, ruining the game.

In addition to knowing the rules of our powers, though, we also need to keep our powers appropriate to the world we’re creating. Giving someone the ability to teleport between worlds, for instance, doesn’t fit for the original D&D world.

Next Shadowrun Sundays, we’ll move on to more worldbuilding notes such as gods, religions, etc. I hope to see you then!

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

As I prepare to speak at SQL Saturday 197 (Omaha Nebraska), I’m listening to Matthew Brimer speak about Database Security & Shrinking Your Attack Surface. It’s an interesting lecture. But since I’m speaking about data recovery plans, I thought I’d post about something along those lines: Recovery Models.

SQL Server has 3 recovery models that are an essential part of any recovery and backup plan: Full, Bulk-Logged, and Simple.

The Full recovery model tracks pretty much every transaction (committed and uncommitted) in the database. If you have Full recovery set on your database, then your Transaction Log needs to be backed up or it will balloon in size as it tracks all inserts, deletes, and updates (which is both an insert and a delete).

The Bulk-Logged recovery model doesn’t track every transaction like the Full model does. Bulk-Logged marks and records the modified database extents (or pages–index or data, depending on the circumstances). This is called Minimal Logging. There is, however, a caveat. Just because the database is set Bulk-Logged, doesn’t mean the whole database is logging the extents / pages. Minimal Logging has prerequisites and if those prereqs aren’t met, then the certain objects are still fully logged.

A table used in Replication cannot be bulk-logged. A table that isn’t table locked (TABLOCK) cannot be bulk-logged. Table “status” also changes how bulk-logging is done. Whether a table is indexed, non-indexed, empty, or loaded can affect what is logged as part of this recovery model. More information can be found by clicking the SQL Server Books Online link. Again, backing up the Transaction Log is essential for preventing run-away log growth.

The last recovery model, Simple, is … well, simple. The Transaction Log isn’t used… Ah, and here we run into a nice little bit of SQL Server myth. Transaction Log backups cannot be run on databases using the Simple Recovery Model. This has led to the belief that SQL Server doesn’t use the Transaction Log for these databases, but that belief is mistaken. Simple recovery does use the Transaction Log, and the Simple recovery databases do use Minimal Logging, just like Bulk-Logged. The major difference between the two is that Simple recovery auto-truncates the Transaction Log, eliminating the need for Transaction Log backups, and that it is only as good as the last data backup. Whereas Bulk-Logged databases can be recovered to the last Transaction Log backup.

Microsoft has a good overview of the Recovery Models online. Understanding these models are an important part of creating a data recovery plan for any server. With these, and a few other business-related tidbits, any DBA can create the best recovery plan (and backup plan) for their business.

If you’re in the Omaha area, stop on by SQL Saturday to hear my presentation. And if you missed it, check out the attachment for my power point presentation.Designing a Data Recovery Solution

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

While writing today’s Writing Prompt Wednesdays post, I was watching Sherlock Holmes. Now that this property is in public domain, everyone wants to write stories for Sherlock, or a Sherlock-like character. So, I decided to indulge that desire.

Da Prompt: Write a Sherlock Holmes style novelette, from the viewpoint of the villain. If you can, stay away from the Steampunk genre (it’s overdone for this particular story type).

Da Wordcount: 7500-15,000 words.

Have fun!

——————————————-

Writers are frequently asked the question “Where do you get your ideas?” The question is a hard one to answer because we all find our inspiration in different places. Some people need to be given prompts, little snippets of ideas to spark their imaginations.

With that in mind, I am posting Writing Prompt Wednesdays. The goal is to inspire writers with exercises meant to train their skills and fire up the creative juices. There are rules. Most prompts will have associated word counts or style instructions. These are not meant to restrict the writer, but give the writer a chance to explore different ways of writing.

If you are an author in search of that one juicy idea, I hope these posts help. If you have ideas for writing prompts, please let me know.

Da Rules:

1) Anything goes so long as you stick to the spirit of the prompt.

2) I ask that if you do publish something based on one of my prompts, that you post the good news (and the link) in the comments of the prompt that inspired your success. You want other people to help you celebrate, right?

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

SQL Saturday is coming, for reals this time. This morning I received an email with the finalized speakers’ schedule and promptly went into a panic when I realized I was out of business cards. DOH! So as I add that to my list of emergency items to order and prepare my deck for posting to the site, it occurs to me that I should, you know, tell everyone to get their butts over to Mammel Hall to hear people talk about all things SQL Server.

Designing a Data Recovery Solution

Track Starts Session Title Speaker
Business Intelligence 08:00 AM Opening Remarks SQLSaturday 197
Business Intelligence 08:00 AM Opening Remarks SQLSaturday 197
Business Intelligence 08:30 AM SSIS 2012: A Deep Dive into the SSIS Catalog Phil Brammer
Business Intelligence 08:30 AM Building Dashboards in PerformancePoint Meagan Longoria
Business Intelligence 10:00 AM Beyond Plateaux: Optimize SSAS via Best Practices Bill Pearson
Business Intelligence 10:00 AM DAX – Get Context Reeves Smith
Business Intelligence 11:30 AM Lunch Break SQLSaturday 197
Business Intelligence 11:30 AM Lunch Break SQLSaturday 197
Business Intelligence 12:45 PM Tabular Models Jeff Renz
Business Intelligence 12:45 PM Windows Azure SQL Reporting Services Leslie Weed
Business Intelligence 02:15 PM Dimension Modeling Design Patterns: Beyond Basics Jason Horner
Business Intelligence 02:15 PM Dimensional Modelling for the DBA Scott Shaw
Business Intelligence 03:45 PM Master Data Services – 101 Reeves Smith
Business Intelligence 03:45 PM Building BI Solutions with Excel 2013 Steve Hughes
Business Intelligence 05:00 PM Raffle SQLSaturday 197
Business Intelligence 05:00 PM Raffle SQLSaturday 197
DBA 08:00 AM Opening Remarks SQLSaturday 197
DBA 08:00 AM Opening Remarks SQLSaturday 197
DBA 08:30 AM Database Security & Shrinking Your Attack Surface Matthew Brimer
DBA 08:30 AM Hardware 201: Selecting Database Hardware Glenn Berry
DBA 10:00 AM Performance baseline your new SQL instance Shawn Meyers
DBA 10:00 AM SQL Server vs. Oracle: The Throwdown! David Klee
DBA 11:30 AM Lunch Break SQLSaturday 197
DBA 11:30 AM Lunch Break SQLSaturday 197
DBA 12:45 PM The Encryption Primer Steve Jones
DBA 12:45 PM Database Health and Performance David Klee
DBA 02:15 PM Amazon RDS and SQL Azure – DB in the cloud Tim Plas
DBA 02:15 PM Extend your Knowledge with Extended Events Kathy Gibbs
DBA 03:45 PM Exposing the Core: SQL 2012 on Server Core Michael Fal
DBA 03:45 PM Dr. DMV: How to Use Dynamic Management Views Glenn Berry
DBA 05:00 PM Raffle SQLSaturday 197
DBA 05:00 PM Raffle SQLSaturday 197
Developer 08:00 AM Opening Remarks SQLSaturday 197
Developer 08:30 AM Windowing Functions: THE Reason to Upgrade to 2012 Kevin Boles
Developer 10:00 AM 2012 TSQL Sweets Bill Fellows
Developer 11:30 AM Lunch Break SQLSaturday 197
Developer 12:45 PM Troubleshooting Query Plan Quality Issues Joseph Sack
Developer 02:15 PM Minimum Database Indexing Dean Nicholson
Developer 03:45 PM Searching Binary Data in SQL Server 2012 Steve Jones
Developer 05:00 PM Raffle SQLSaturday 197
General 08:00 AM Opening Remarks SQLSaturday 197
General 08:30 AM How to be DBA and retire rich Sudhir Gajre
General 10:00 AM Designing a Data Recovery Solution Brandie Tarvin
General 11:30 AM Lunch Break SQLSaturday 197
General 12:45 PM Tips and Tricks for Auditing in SQL Server Ronald Yenko
General 02:15 PM Getting Started with PowerShell’s Job Infrastructure Jeff Hicks
General 03:45 PM Getting Started with PowerShell Workflow Jeff Hicks
General 05:00 PM Raffle SQLSaturday 197

My SQL Saturday session starts at 10 a.m. in room 119, and I’m seriously thinking of just going to that room to start off with to hear Sudhir Gajre talk about “How to be DBA and retire rich”. Of course, there are so many cool things, it’s hard to pick just one session to follow. And after a day of crunchy learny stuff, there’s the really cool stuff raffle in which someone launches baloney into the audience and watches the rats scramble for the choicest bits. (Kidding). The raffle is a great place to win even more free training (classes that would ordinarily cost money), books, t-shirts, and free software. Me, I could use a copy of SQL 2012 to play with. @=)

If you’re in the area, stop on by. Registration is free and you can sign up the morning of the event. In addition, there are three precon training events at Blue Cross / Blue Shield nearby (these cost money) that you can attend.

Is there a better way to learn SQL Server than attending SQL Saturday? In some cases, yes. Is there a cheaper way to learn SQL Server than attending SQL Saturday? HA! No. So take some time and learn some technical tidbit that will turn your world inside out and resolve whatever mystery you’re currently having trouble with!

I look forward to seeing you there.

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

Depending on what type of DBA you are, you might find yourself using different database tools, but the most important tool (in my opinion) is SSMS – also known as SQL Server Management Studio.

SSMS is part of the SQL Server client toolset. SQL Server does work without the client tools being installed and the client tools can be installed on a computer that doesn’t have SQL Server installed on it. The client tools are typically installed as part of the SQL Server installation. If you don’t see them, don’t panic. Just grab the DVD (or .msi install file) and alter your SQL Server install to include them.

NOTE: Before installing the client tools on multiple computers, make sure you have the proper licensing. Microsoft is really picky about these things and you don’t want to get fined for overusing the software.

Once SSMS is installed, it can be found under the Start -> Programs -> Microsoft SQL Server menu as “SQL Server Management Studio.” The icon is a little wrench-crossing-a-hammer with a little yellow cylinder in the upper left hand corner (a database symbol). When you open it up, the default settings will ask you to connect to a database. The connect box looks like this:

Database Tools – SSMS Connection Box

SSMS is the GUI (Graphical User Interface) most DBAs use for managing all the working parts of SQL Server. It does not manage everything, but it covers the essentials: Instances, Databases, Security, Server Objects, Resources, object properties, SQL Agent objects, Database Mail, Jobs, Integration Services (management only), Analysis Services (management only), and a lot more. SSMS has an Object Explorer which can be used to monitor and check all of the above, a summary window (also called the Object Explorer Details) which focuses on all items within a specific instance, and query windows (as many as you can deal with) which can be used to write and run T-SQL and some CLR code.

In my experience, SSMS is THE power tool of SQL Server database administration. I’m a “jack of all trades” DBA and SSMS is what I use 90% of the time. I always have at least 2 copies open on my desktop, one in each monitor. Knowing how to get around in SSMS is essential for any type of DBA, and learning it is the first step in becoming a DBA. It’s also a lot easier than writing T-SQL in BIDS or Visual Studio (in my opinion).

If you’re interested in more information, Microsoft has a SSMS tutorial here. Stay tuned to SQL Saturdays for more information on the SQL Server database tools.

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

Today we’re taking a page from reality for Writing Prompt Wednesdays.

Whether the tax man is Cuthulu’s right hand monster, the United Nations are paying annual taxes to an alien empire, or the ancient Greeks are paying their annual tithes to the city-state next door, tax season is a pain.

Da Prompt: Take a page from either side of the equation, the collector, the auditor, or the payee, and write a tax-related speculative fiction. It can be horror, fantasy, science fiction, or any of the sub-genres.

Da Wordcount: 1000+ words.

Have fun!

——————————————-

Writers are frequently asked the question “Where do you get your ideas?” The question is a hard one to answer because we all find our inspiration in different places. Some people need to be given prompts, little snippets of ideas to spark their imaginations.

With that in mind, I am posting Writing Prompt Wednesdays. The goal is to inspire writers with exercises meant to train their skills and fire up the creative juices. There are rules. Most prompts will have associated word counts or style instructions. These are not meant to restrict the writer, but give the writer a chance to explore different ways of writing.

If you are an author in search of that one juicy idea, I hope these posts help. If you have ideas for writing prompts, please let me know.

Da Rules:

1) Anything goes so long as you stick to the spirit of the prompt.

2) I ask that if you do publish something based on one of my prompts, that you post the good news (and the link) in the comments of the prompt that inspired your success. You want other people to help you celebrate, right?

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

Today’s Writing Prompt Wednesday takes an old trope and gives it a new twist.

Many of us have heard the whole “Are we there yet?” routine. Not only is it used in multiple cartoons (like the Smurfs), but it’s a favorite staple of children world-wide as they tire of whatever road trip they’ve been dragged on. The question quickly gets old and is a great indicator of how bored everyone is. So let’s change that.

Da Prompt: Write an exciting “Are We There Yet” speculative fiction story using the below three words. It can be horror, fantasy, science fiction, or any of the sub-genres.

Da Words: Poker, Trout, Moisturizer.

Da Wordcount: 500-3000 words.

Have fun!

——————————————-

Writers are frequently asked the question “Where do you get your ideas?” The question is a hard one to answer because we all find our inspiration in different places. Some people need to be given prompts, little snippets of ideas to spark their imaginations.

With that in mind, I am posting Writing Prompt Wednesdays. The goal is to inspire writers with exercises meant to train their skills and fire up the creative juices. There are rules. Most prompts will have associated word counts or style instructions. These are not meant to restrict the writer, but give the writer a chance to explore different ways of writing.

If you are an author in search of that one juicy idea, I hope these posts help. If you have ideas for writing prompts, please let me know.

Da Rules:

1) Anything goes so long as you stick to the spirit of the prompt.

2) I ask that if you do publish something based on one of my prompts, that you post the good news (and the link) in the comments of the prompt that inspired your success. You want other people to help you celebrate, right?

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

The best writing advice ever is the advice that comes from our own writing experiences. Authors, agents, and editors can talk left and right about the best and worst ways to do things in the publishing world. But it all comes down to one truth: What works best for you?

I blog about what I like, what I don’t like, what I think works, and what I think won’t / doesn’t work. Just because some things work for me doesn’t mean they will work for you. The same is true for advice that you see on the blogs and websites of others. Just because it worked for them, doesn’t mean it will work for you.

At some point in your writing career, you have to stop reading advice and try something. Do something. Whether you test advice given to you by others or whether you decide to go your own way, just do it. Take a chance, take a risk, and remember whatever you do, you are the one who has to deal with the consequences, both good and bad.

A few things to remember while you’re on this grand adventure we call writing:

1) There will always be someone willing to take your money and your words and leave you with nothing.

2) There will always be people giving bad advice while believing they know everything there is to know about the industry.

3) There will always be a few gems of good advice hidden among the bad and things that are repeated by multiple agents, authors, and editors tend to be those gems.

4) If you don’t write and you don’t submit, you’re not going to get published.

5) The super-secret password / handshake / club card does not exist, but if you pay me a million U.S. dollars, I’ll create one just for you. I just don’t guarantee it’ll do you anything but look cool. @=) (See # 1).

What all my advice boils down to is this: Write. Write more. Write even more. Then edit, rewrite, and submit. Lather, rinse, repeat. That’s how we get published.

Originally published at Ramblings from the Flip Side (Site under construction). You can comment here or there.

Today’s Shadowrun Sundays addresses game design. Designing a game from scratch requires a lot of work. There’s world building that needs to be done, threats that need to be created, rules that need to be set up, and then everything needs to be tested. It sounds easy, but designing the game is only half the battle. After game creation comes the business side of the coin: networking, marketing, distribution, brand building, and sales. I’m no expert at game design, but the steps seem similar to how fiction writing works.

Everything starts with a concept, a single sentence snippet that gives a grand overview of the game world. In D&D, it would be something like “A medieval world with magic and gods that combines the high fantasy worlds of Tolkien and Camelot.” In that single sentence, we have what time period the game will be placed in, what types of weapons and armor will be available to our players, the basic idea for the religious setting, and two initial threats: magic and torqued-off gods.

From this sentence, we start our world building. Medieval society tends to be very fractured. Even empires are small due to traveling constraints and the burden of supporting professional armies. On the other hand, we’ve given ourselves magic, which means we can break the normal rules of how traveling works. Teleportation and magical portal gates could be involved to speed things along. But before we get ahead of ourselves, we need to start with the basics. The number of countries, ethnicities, societies and cultures we want.

Richard White writes an fantastic series of World Building articles (Terra Incognito) in Penumbra eMag, starting in Volume 1, Issue 5. Richard starts with a concept, then builds up to that concept from the very beginning by defining the land first, which includes shapes and climates, then moves on to people (indigenous and immigrant), governments, religions, trade and finance, and even politics and mythology. I don’t quite work that way. I start my world building with the initial concept and reverse engineer the society I want.

My WIP novel, Circle of Fire, starts with mid-European medieval society fused with elements of the Roman Empire, Scheherazade’s Arabian Nights world, and Greco-Norse mythology. In order to pull that together, I needed to map out my world, decide my climates (much like Richard did), then find the reason why all these elements got fused together. Unlike Richard, though, I knew my pantheon and how my majority religion worked before I got to designing kingdoms and mapping out migratory patterns.

It doesn’t matter what direction we work from. It only matters that we answer the basic questions that will be needed for gameplay. World building isn’t just a matter of having background color. The world dictates the rules of the game and is an essential building block for attracting players and long-term fans. Even board game designers are aware of this. Look at Monopoly and Ticket to Ride for examples. There are stories behind these games, creating a common culture for the fans that make the game memorable. If our game world is memorable, if it gives something for the fans to apply to real life situations (like the phrases “Critical Failure” and “Automatic success!” when achieving something fantastic), the game is more likely to be successful.

World building is just one component of game design, though. It is both easy and hard, over-engineered and overlooked. Too much world building can sink a game as fast as not enough world building. Finding the balance is key.

What do you think about games and world building? Does it help or hinder your game play?