January 5, 2015 at 7:05 am
Grant Fritchey (1/5/2015)
IncidentalProgrammer (1/5/2015)
GilaMonster (12/30/2014)
IncidentalProgrammer (12/29/2014)
Fortunately, I won't have to worry about doing the backups in SQL, myself. Corporate backs everything up automatically on a daily basis, and I'm told that to restore, all I'll need to do is submit a ticket, and restorations usually take place in about 30 minutes. So that's one thing that's not on my plate.I'd be very doubtful about that. They probably take file backups, but file backups are not SQL backups and backups of the database files aren't always usable, especially if they're taken when the system is in use. Your database, you need to make sure about the backups, because you'll be the one people are yelling at if what corp restores won't attach and isn't usable.
That sounds like something I definitely need to check up on. Thanks for the tip! And I'm sorry, but still new to all of this...in checking with IT to see which is the case, what would be a good way to phrase that so that I get an exact answer? Because when I asked before, I got the info above about their backups, so I'm apparently going about it wrong.
Try using the phrase "transactionally aware" as in "Is the backup program transactionally aware? Will it support the durability property of my database files which are ensured by the SQL Server operating system? Really? Cool. Let's perform a test restore just so I can see it in action."
That's how I'd go about it. If they don't know about transactions and durability of database files, then chances are high that it's just a file backup process and isn't aware of how databases work (and they do work differently). this would mean you need to get a backup running internally to a location that the file backup can then capture. That way you'll be covered.
Thanks so much! Still struggling with terms, myself. I'll see what I can find out.
January 5, 2015 at 7:15 am
Grant Fritchey (1/5/2015)
IncidentalProgrammer (1/5/2015)
Grant Fritchey (12/30/2014)
IncidentalProgrammer (12/29/2014)
Fortunately, I won't have to worry about doing the backups in SQL, myself. Corporate backs everything up automatically on a daily basis, and I'm told that to restore, all I'll need to do is submit a ticket, and restorations usually take place in about 30 minutes. So that's one thing that's not on my plate.I don't trust that at all. SQL Server really does do things a little differently. The ACID properties of the transactions means that standard backup routines may not be able to restore things properly. I'd suggest a test of this when you can, assuming that data loss would be an issue for you.
Would it make any difference that they use SQL Server for other things worldwide, and should have all of this figured out already? Corporate seems to keep everything pretty much in their hands; we even have to call them for password resets. Would it be possible for them to be doing the kind of backups I'd need, or is that something that can only be done on location?
Yeah, it's absolutely possible. But it's not something I would assume, ever. I'd validate it. And the best way to validate it is to get a restore. Plus, a lot of enterprises have multiple support teams. There may be one support team for your IT infrastructure who works with DBAs and databases and knows all about this stuff and is on top of it and another team that works primarily with user laptops, etc., who really don't have a clue about SQL Server and locked files and ACID properties, etc. I've seen that pretty frequently in different enterprises. So, when there are silo applications like you're working with, they can be completely unsupported by the greater IT infrastructure.
This reminded me of some questions on the application I had to fill out to get my SQL Server. Looking at it again, I really think they will have the kind of backups I need. Still going to ask, of course, but it gives me hope!
January 5, 2015 at 7:17 am
The link I gave you for the data types is part of Microsoft's Book On Line for SQL Server. That and TechNet are two great resources for you, but they are a little dry. There are quite a few decent bloggers out there that explain the same things a little better and give different examples.
For many of the Books On Line articles, I read the beginning and then skip to the end where they have a lot of examples, and then go back and finish reading the article. It helps me visualize better.
And I know I've said this before, but I can't emphasize it enough. Get the Dev version of SQL Server and put it on your work computer. It is only $50 and it will help so much. You can use it to play around and test ideas and never have to worry about production or even corporate. I usually get a copy for myself at home too, but you don't need to do that unless you're having fun with it. : -)
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
January 6, 2015 at 6:17 am
Along with a schedule of backups, I got this from the big DBA at corporate, so I think I'm set on backups:
"The full backups would be a guaranteed recovery point (in case of corruption), and in some cases we will be able to recover to any desired point in time."
Sound about right?
I also found out I had my wires crossed. The version I have is Dev, and they'll copy it into Production when I'm ready.
January 6, 2015 at 6:59 am
IncidentalProgrammer (1/6/2015)
Along with a schedule of backups, I got this from the big DBA at corporate, so I think I'm set on backups:"The full backups would be a guaranteed recovery point (in case of corruption), and in some cases we will be able to recover to any desired point in time."
Sound about right?
I also found out I had my wires crossed. The version I have is Dev, and they'll copy it into Production when I'm ready.
Yeah, I think that sounds like things are in good order. Especially since you're going to be working on Dev and there's a prod machine. All good.
Just in terms of your own education though, you might still want to learn how to do the backups & restores. Since you're moving into the data arena, these are must-have skills.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 6, 2015 at 7:03 am
Grant Fritchey (1/6/2015)
IncidentalProgrammer (1/6/2015)
Along with a schedule of backups, I got this from the big DBA at corporate, so I think I'm set on backups:"The full backups would be a guaranteed recovery point (in case of corruption), and in some cases we will be able to recover to any desired point in time."
Sound about right?
I also found out I had my wires crossed. The version I have is Dev, and they'll copy it into Production when I'm ready.
Yeah, I think that sounds like things are in good order. Especially since you're going to be working on Dev and there's a prod machine. All good.
Just in terms of your own education though, you might still want to learn how to do the backups & restores. Since you're moving into the data arena, these are must-have skills.
I don't suppose it works anything like backing up or restoring Access? I wish. I know how to do it in Access, at least.
I'll see what I'm able to do, once I get in and start getting my hands dirty. There's got to be some way for meto back it up, at least just for practice.
January 6, 2015 at 7:12 am
IncidentalProgrammer (1/6/2015)
Grant Fritchey (1/6/2015)
IncidentalProgrammer (1/6/2015)
Along with a schedule of backups, I got this from the big DBA at corporate, so I think I'm set on backups:"The full backups would be a guaranteed recovery point (in case of corruption), and in some cases we will be able to recover to any desired point in time."
Sound about right?
I also found out I had my wires crossed. The version I have is Dev, and they'll copy it into Production when I'm ready.
Yeah, I think that sounds like things are in good order. Especially since you're going to be working on Dev and there's a prod machine. All good.
Just in terms of your own education though, you might still want to learn how to do the backups & restores. Since you're moving into the data arena, these are must-have skills.
I don't suppose it works anything like backing up or restoring Access? I wish. I know how to do it in Access, at least.
I'll see what I'm able to do, once I get in and start getting my hands dirty. There's got to be some way for meto back it up, at least just for practice.
It is actually really easy. The hardest part is finding a space to put the backup file. : -)
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
January 6, 2015 at 7:20 am
Stefan Krzywicki (1/6/2015)
IncidentalProgrammer (1/6/2015)
Grant Fritchey (1/6/2015)
IncidentalProgrammer (1/6/2015)
Along with a schedule of backups, I got this from the big DBA at corporate, so I think I'm set on backups:"The full backups would be a guaranteed recovery point (in case of corruption), and in some cases we will be able to recover to any desired point in time."
Sound about right?
I also found out I had my wires crossed. The version I have is Dev, and they'll copy it into Production when I'm ready.
Yeah, I think that sounds like things are in good order. Especially since you're going to be working on Dev and there's a prod machine. All good.
Just in terms of your own education though, you might still want to learn how to do the backups & restores. Since you're moving into the data arena, these are must-have skills.
I don't suppose it works anything like backing up or restoring Access? I wish. I know how to do it in Access, at least.
I'll see what I'm able to do, once I get in and start getting my hands dirty. There's got to be some way for meto back it up, at least just for practice.
It is actually really easy. The hardest part is finding a space to put the backup file. : -)
Oh, good! The way everyone's been talking about it, I was worried it was going to be complicated. I am still worried about what I'm able to do, since I know corporate is backing it up.
January 6, 2015 at 7:25 am
Nah, the basics of backup are, well, basic. You'll be fine. Restore gets marginally more complicated. But then it can get crazy as you start to add wrinkles. Don't sweat all that though. Just know how to do a basic backup and a basic restore. It'll save your bacon.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 6, 2015 at 7:28 am
Grant Fritchey (1/6/2015)
Nah, the basics of backup are, well, basic. You'll be fine. Restore gets marginally more complicated. But then it can get crazy as you start to add wrinkles. Don't sweat all that though. Just know how to do a basic backup and a basic restore. It'll save your bacon.
Thanks so much for the tips! 🙂
January 7, 2015 at 11:21 am
It's always interesting, starting out like that and learning new things. Access is a good tool and I use it a lot as my front-end to talk to SQL Server which is holding all my data and doing all the heavy lifting. But Access has its limits and that's where SQL Server comes in.
To reiterate what so many others have said, do as much development in SQL Server as possible. It's different enough that you can run in to problems. A common issue that I've seen in Access is people using spaces and special characters in field and table names, stick with only using letters, numbers, and underscores in field and table names: you'll save yourself a world of grief. You'll be doing lots of attaching and refreshing tables and you'll learn a lot by doing so.
Something to watch for: when you upsize your Access to SQL Server, your Text fields will become NChar. The N represents Unicode characters and allows you to store any character set with funky punctuation and umlauts and such: if you don't need to store international character sets, remove the N because Unicode doubles the space requirements.
Oh, meant to mention: developer editions can be ordered from Amazon for about $50. They can do everything that the Enterprise edition can do, but it's licensed strictly for development, not for production. Still, it's an excellent learning tool. And I can recommend Patrick LeBlanc's Microsoft SQL Server 2012 Step By Step, printed by Microsoft Press. That'll give you a pretty good introduction to SQL development along with info on maintenance and management.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
January 7, 2015 at 11:25 am
Wayne West (1/7/2015)
It's always interesting, starting out like that and learning new things. Access is a good tool and I use it a lot as my front-end to talk to SQL Server which is holding all my data and doing all the heavy lifting. But Access has its limits and that's where SQL Server comes in.To reiterate what so many others have said, do as much development in SQL Server as possible. It's different enough that you can run in to problems. A common issue that I've seen in Access is people using spaces and special characters in field and table names, stick with only using letters, numbers, and underscores in field and table names: you'll save yourself a world of grief. You'll be doing lots of attaching and refreshing tables and you'll learn a lot by doing so.
Something to watch for: when you upsize your Access to SQL Server, your Text fields will become NChar. The N represents Unicode characters and allows you to store any character set with funky punctuation and umlauts and such: if you don't need to store international character sets, remove the N because Unicode doubles the space requirements.
Related to converting the text fields, this is part of the reason I said I'd help when it came time for conversion. You may want char, you may want varchar, you may want nchar or nvarchar depending on usage and planned usage. It helps to have someone to talk to when making those decisions the first time or two. You'll get your own preferences quickly.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
January 13, 2015 at 9:01 am
IncidentalProgrammer (1/6/2015)
Grant Fritchey (1/6/2015)
Nah, the basics of backup are, well, basic. You'll be fine. Restore gets marginally more complicated. But then it can get crazy as you start to add wrinkles. Don't sweat all that though. Just know how to do a basic backup and a basic restore. It'll save your bacon.Thanks so much for the tips! 🙂
A little late to the game... Once you've learned the basics of backups, research restore strategies. Knowing how to do backups is one thing, knowing what types of backups to do when is based entirely on how you want your recovery to go. If you can knock this one out of the park, your bosses will love you.
Viewing 13 posts - 46 through 57 (of 57 total)
You must be logged in to reply to this topic. Login to reply