May 14, 2013 at 11:34 pm
generally as a DBA what type of tickets we will get....? send some samples
May 15, 2013 at 1:54 am
Tickets? As in "what will you be asked to do when you take a job as a DBA?" Are you considering interviewing for a DBA job or are you already in a DBA position?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
May 15, 2013 at 3:25 am
i am not DBA, i want to become a DBA that's why i am asking
May 15, 2013 at 8:00 am
There are many types of DBAs. System, Development/Application, Production Support, to name a few. The responsibilities of each type actually vary widely, and within each type they can change based on which area of the product you might be focused, e.g. OLTP, Data Warehouse, Reporting, etc. Do you have any sense of which direction you might be interested in pursuing?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
May 15, 2013 at 10:47 pm
Actually i am interested in production server DBA
May 15, 2013 at 11:14 pm
In my experience, and know that if you ask 10 people it's possible to get 10 different answers, a "Production DBA" does environment support and is usually on-call 24/7 for some portion or time per month. They'll typically handle things like:
- deploying code in production
- monitoring and alerting
- setting up Logins and Users, I.e. Handle Instance and Database security
- patching and upgrades
- backups
- scheduled jobs
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
May 15, 2013 at 11:25 pm
As my knowledge in this mainly we have 3 types of tickets they are 1. user req tickets, 2. Intigretaion req tickets, 3. change req tickets.
i want know what is the diff in this three and give me some examples for each one.
May 16, 2013 at 5:36 am
who motivated to u became a production DBA
May 16, 2013 at 6:02 am
personally i am interested in this, why????
May 16, 2013 at 6:10 am
You want to be a production DBA don't focus on process, in every company process will vary so u focus on technical prospective 😛 it will help as a perfect production DBA good luck :-):-):-)
May 16, 2013 at 6:11 am
cheekatla.rakesh (5/15/2013)
As my knowledge in this mainly we have 3 types of tickets they are 1. user req tickets, 2. Intigretaion req tickets, 3. change req tickets.i want know what is the diff in this three and give me some examples for each one.
All of these are going to be specific to each persons environment. What is it your are trying to learn from this?
May 16, 2013 at 6:18 am
rather than thinking of tickets you might encounter, think of the responsibilities the production DBA has, and evaluate yourself on which items you cna do, and which you want to practice with;
here's some notes i have grabbed for dba responsibilities:
http://www.sqlservercentral.com/articles/Administration/dbaroles/517/
http://www.sqlservercentral.com/articles/Administering/thevalueofadba/1806/
http://www.sqlservercentral.com/articles/State+of+the+Business/deathoftheproductiondba/432/
http://www.sqlservercentral.com/articles/Certifications/3176/
http://www.sqlservercentral.com/articles/Miscellaneous/2989/
The following tasks should be completed on a daily basis:
Check to make sure the SQL Server is still online and that you still have connectivity.
Check the NT and SQL Server logs for any errors or problems.
Ensure that no SQL Server job has failed.
Resolve any problem tickets.
Close any outstanding change tickets.
Perform the necessary backups, whether transactional or complete.
Check the general health of the server (space, CPU utilization, memory) to confirm there are no issues.
Track locking issues, including deadlocks, blocking, and lock timeouts.
The following tasks should be completed on a weekly basis:
Perform necessary database backups.
Remove any unneeded space from the transaction log and data files.
Perform any necessary index tuning, including defragmenting the indexes.
Execute UPDATE STATISTICS if auto-update statistics has been turned off.
The following tasks should be completed on a monthly basis:
Perform necessary database backups (including a complete backup of the OS and supporting third-party application files).
Apply any patches or service packs for SQL Server.
Run System Monitor to confirm that your server is operating close to its baseline. Update your baseline documentation to reflect this month’s numbers.
Perform a complete system restore of the server’s database onto a new server from a random day. Check the health of the restored database afterward by running DBCC CHECKDB.
Run sqldiag.exe on your server and document the results into a central repository.
Test your alerts to confirm that they still work.
some notes from a post by Jeff Moden:
Protect the data, at all costs.
Protect the server the data is on, at all costs.
Help most developers tune queries while teaching them what good set based SQL actually is and why it's important to an RDBMS.
Answer the bloody phone.
Conduct code reviews before promoting code.
Promote code.
Find queries hogging the CPU/Disk.
Find the developer responsible for the above.
Find the manager for the above.
Pummel them both until they agree to rewrite the code today!
Answer the bloody phone.
Answer 10,000 dumb questions per day because lots of folks really have no clue how to write SQL correctly.
Tell managers why the code they want to go in, isn't (dangerous to the data or the system).
Attend project meetings where the users usually think they know more about correct database design than you.
Document the "system" because the users were wrong.
Answer the bloody phone.
Help repair totally undocumented code that broke in the face of scalability.
Help repair totally undocumented code that broke because someone wanted it real bad and that's the way they got it.
Help developers figure out what the undocumented SQL does.
Answer the bloody phone.
Find out which undocumented code is causing the deadlocks even if it's embedded in Jave or C#.
Write reports on the deadlocks and why the server "seemed sluggish" today and every day.
Write "Code Guidelines" to prevent undocumented code in the future.
Buy a new bat with a nail in it to help you enforce the new "Code Guidelines".
Answer the bloody phone.
Explain to migration experts why PL/SQL and T-SQL cannot be run in SQL Server and Oracle, respectively.
Answer the bloody phone.
Explain to everyone from the President of the Company down to the Janitor why no one can have "SA Privs" and why they can't use xp_CmdShell without going through a proxy.
Attend 10 hours of "Sensitivity Training" each week because people think you're too mean just because you made 2 developers cry and 1 leave the country.
Drink too much beer because deep in your heart, you know you're not mean enough.
Answer the bloody phone.
Interview more *&*&&$%$# Developers that you're gonna have to train all over again.
Answer the bloody phone.
What the heck, it's a living 😉
--Jeff Moden
--------------------------------------------------------------------------------
Lowell
May 16, 2013 at 6:19 am
Thanks for your advise
May 16, 2013 at 6:24 am
Really thanks man...
I have one more question that is why we apply service packs on server
May 16, 2013 at 6:32 am
its simply bug fixing on your version
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply