An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.
One of a set of tools we're offering as a way of saying thank you for being a part of the community.
Course Of The Month
Become a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Dynamically Growing Sybase Database
Posted on 2013-11-11
I am building a little installation/packaging script that deploys various database schema items and procedures. Right now, I just use this to make the database:
CREATE DATABASE dbname
GO
However,
when i point my little package at my larger databases, they quickly fill up the allotted space.
I am not clear how to create a database that has space to grow on sybase....is there some sort of parameter CREATE DATABASE parameter that allows it room to grow, or do I have to supply a specific size per database?
CREATE DATABASE dbname
GO
However,
when i point my little package at my larger databases, they quickly fill up the allotted space.
I am not clear how to create a database that has space to grow on sybase....is there some sort of parameter CREATE DATABASE parameter that allows it room to grow, or do I have to supply a specific size per database?
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
2
3 Comments
Active 1 day ago
Depending on your ASE version, you can indeed set your databases to automatically grow.
When you don't specify a size like you've done here, you get the default size which again depending on your ASE version is either 2MB or 3MB - hardly enough for any serious work.
You also don't have any control over where the database gets placed which may have effects you don't want... by default the "master" device is available for creating and extending ("altering") user/application databases onto, and this for many reasons is poor practice.
Strongly recommend you create your databases with an explicit size, explicitly on one or more devices. I myself am not a fan of auto-growing databases as I think that causes more trouble than it's worth... if there's a run-away process, without auto-grow it eventually fills the database, which is bad, but with auto-grow it eventually fills all your devices and potentially your file system... which I think is worse.
The chapters in the ASE System Admin Guide about devices and databases are pretty clear on how this works. Well worth taking a look at. The full syntax you might benefit from is:
CREATE DATABASE [name]
ON [device_D1] = [size]
[, [device_D2] = [size], ... ]
LOG ON [device_L1] = [size]
[, [device_L2] = [size], ...]
GO
If you specify size as an integer is is interpreted as megabytes. Because there is so much confusion even in the IT industry about how many megabytes are in a gigabyte, I suggest you instead specify size as a string, i.e. "2G" which is unambiguous.
The above syntax also separates data from log in the database. This is important for any serious production database, and I again refer you to the manuals for the details on why. For now I'll say you can't do incremental backups without this.
When you don't specify a size like you've done here, you get the default size which again depending on your ASE version is either 2MB or 3MB - hardly enough for any serious work.
You also don't have any control over where the database gets placed which may have effects you don't want... by default the "master" device is available for creating and extending ("altering") user/application databases onto, and this for many reasons is poor practice.
Strongly recommend you create your databases with an explicit size, explicitly on one or more devices. I myself am not a fan of auto-growing databases as I think that causes more trouble than it's worth... if there's a run-away process, without auto-grow it eventually fills the database, which is bad, but with auto-grow it eventually fills all your devices and potentially your file system... which I think is worse.
The chapters in the ASE System Admin Guide about devices and databases are pretty clear on how this works. Well worth taking a look at. The full syntax you might benefit from is:
CREATE DATABASE [name]
ON [device_D1] = [size]
[, [device_D2] = [size], ... ]
LOG ON [device_L1] = [size]
[, [device_L2] = [size], ...]
GO
If you specify size as an integer is is interpreted as megabytes. Because there is so much confusion even in the IT industry about how many megabytes are in a gigabyte, I suggest you instead specify size as a string, i.e. "2G" which is unambiguous.
The above syntax also separates data from log in the database. This is important for any serious production database, and I again refer you to the manuals for the details on why. For now I'll say you can't do incremental backups without this.
Thanks joe,
I ended up doing something like this (for the benefit of those who are looking, i had a hard time figuring out the device part..)
-- Data Device
disk init
name = 'do02_data',
physname = 'C:\sybase\data\do02data.d
size = '15G',
directio = true,
skip_alloc = true
go
-- Log Device
disk init
name = 'do02_log',
physname = 'C:\sybase\data\do02log.da
size = '7G',
directio = true,
skip_alloc = true
CREATE DATABASE do02 on do02_data = '15G' LOG ON do02_log = '7G' -- will take some time
GO
sp_dboption do02, 'select into/bulkcopy', true
GO
The 'select into/bulkcopy' was also needed if you're going to use BCP right afterwards.
I just put instructions in my package for the end user to modify these values as needed.
I ended up doing something like this (for the benefit of those who are looking, i had a hard time figuring out the device part..)
-- Data Device
disk init
name = 'do02_data',
physname = 'C:\sybase\data\do02data.d
size = '15G',
directio = true,
skip_alloc = true
go
-- Log Device
disk init
name = 'do02_log',
physname = 'C:\sybase\data\do02log.da
size = '7G',
directio = true,
skip_alloc = true
CREATE DATABASE do02 on do02_data = '15G' LOG ON do02_log = '7G' -- will take some time
GO
sp_dboption do02, 'select into/bulkcopy', true
GO
The 'select into/bulkcopy' was also needed if you're going to use BCP right afterwards.
I just put instructions in my package for the end user to modify these values as needed.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Originally, this post was published on Monitis Blog, you can check it
here
.
In business circles, we sometimes hear that today is the “age of the customer.” And so it is. Thanks to the enormous advances over the past few years in consumer techno…
Part Two of the two-part Q&A series with MalwareTech.
There's a multitude of different network monitoring solutions out there, and you're probably wondering what makes NetCrunch so special.
It's completely agentless, but does let you create an agent, if you desire.
It offers powerful scalability …
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
Suggested Courses
Earn Certification
HTML5 Specialist - Certification
Free withPremium
Course of the Month4 days, 13 hours left to enroll
635 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.