Download Oracle Database on SolidFire

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Entity–attribute–value model wikipedia , lookup

Open Database Connectivity wikipedia , lookup

Concurrency control wikipedia , lookup

Relational model wikipedia , lookup

Microsoft Jet Database Engine wikipedia , lookup

Oracle Database wikipedia , lookup

Functional Database Model wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Database wikipedia , lookup

Extensible Storage Engine wikipedia , lookup

ContactPoint wikipedia , lookup

Database model wikipedia , lookup

Clusterpoint wikipedia , lookup

Transcript
Get More Value From Your
Oracle Database on
Next Generation Storage
Agenda
•
Database and storage review
•
Legacy storage vs storage for the next generation data center
•
Practical examples
– RMAN incremental merge window
– Data Guard Standby lag
– Query response time for heavily indexed VLDB
– Clone deployment for secondary processing (test/dev/qa)
Key Takeaways
•
Protect and distribute data with a hash
– Better than RAID, mandatory at scale
•
Did he just
say to use
flash for
backup?
Deploy flash with shared scale-out architecture
– QoS control guarantees application throughput
•
Use flash for backup, standby, DSS, test/dev/QA databases
– Better, faster, and cheaper
– Deduplication and shared economics
•
More work from same resources yields more value
How This Helps Oracle Database Applications
•
Better protection (RTO)
– Shrink RMAN incremental apply window, SWITCH DATABASE TO COPY
– Eliminate Data Guard Standby lag
•
Faster query response time
– All-flash performance
•
Cheap database clones
– Easier to deploy, easier to maintain, minimal media consumption
•
Deployment agility
– Quickly adapt to changes, rapid prototyping
Database and Storage Review
Storage Use Cases for Oracle Database
•
OLTP applications
•
DSS applications
•
Database consolidation
•
Data protection
•
Disaster recovery
•
Test, development, and quality assurance
Production
Backup
Secondary
Reporting
Applications and Copies
Prod
RMAN
Bkup
c1
c4
Oracle
DG
c3
RMAN
Clone
c2
Rep
Clone
c2
Oracle
ADG
c3
Rep
Clone
c2
c3
Reporting
Test
Dev
QA
c4
c5
c6
c7
Rep
Clone
Application and Database Block Diagram
Oracle
Instance
SGA
Application
Buffer
Cache
Log
Buffer
User P.
DBWn
CKPT
LGWR
Data
Files
Contol
Files
Online
Redo
ARCn
Srvr P.
Oracle
Database
RMAN
Arch
Redo
Bkup
Sets
Image
Copies
Recovery
Files
System Block Diagram
SolidFire Node
DB Server
Application
Instance
Database Reads
Block
Service
Write
Flash
Cache
Media
Slice
Service
Write
Write
Cache
Cache
ASM
Database Writes
mp
sd
iscsi
iscsi
TCP
TCP
IP
IP
drvr
drvr
NIC
Network
NIC
Legacy Storage vs Storage for the
Next Generation Data Center
Problem with RAID
100x
Solution to RAID with SolidFire HelixTM
•
Shared-nothing architecture
•
Distributed replication algorithm (hash)
•
Advantages vs. RAID
A
G
– Minimal performance impact during drive rebuilds
F
B
– Industry leading drive rebuild time: minutes
C
H
A
C
E
G
– Self-healing – Automatic and complete
restoration of redundancy after failure
D
– Upgrade software and hardware non-disruptively
E
B
D
H
F
Problem with Scale Up Storage
Bottleneck
Controller
Lots of $$$
Little Space
Out of
Bandwidth!
Diminishing
Return
Solution with Scale Out Storage
Low $
Scale
Capacity
Bandwidth
Scale Out with SolidFire
•
•
New nodes added or removed dynamically
and non-disruptively
New capacity and performance immediately
available
– IOPS load is rebalanced across new nodes
– Block data redistributed so that all drives have same
amount of data
•
•
Data automatically rebalanced when cluster
size changes
No manual tasks needed for system balancing
A
B
C
F
C
A
H
G
D
B
E
G
D
E
F
H
In preparing for battle, I have always found that plans
are useless but planning is indispensable.
Dwight D. Eisenhower
The Future in the Next Generation Data Center
•
All-flash implementation - no disk
– Performance at any transfer size
– Eliminates an entire class of tuning work
•
Hash-based replication - no RAID
– Uniform distribution and redistribution over arbitrary resources
– Dedup is fundamental to architecture, not an afterthought
– Resilver at aggregate media speed, not individual media speed
•
Hardware gets softer
– Decouple performance and capacity
– Guaranteed bandwidth from a knob, not a device
Practical Examples
Legacy RMAN Merge Architecture
$$$
IOPS
DB Server
IOPS
DB Server
DB Server
MB/s
DB Server
MB/s
<$
Legacy RMAN Merge Problem
•
Imbalance between prod and backup write bandwidth
– Creates a bottleneck
•
Merge takes too long
– Get stuck in bottleneck, never catch up
•
Full restore/recovery process if there is an outage
– No RMAN SWITCH DATABASE TO COPY
– New prod storage, restore database, recover database, apply redo
•
Exposure to double-fault during long resilver time
– RAID processing bottleneck on single drive
Next Generation Solution for RMAN Merge
Test
IOPS
DB Server
IOPS
QA
DB Server
DB Server
MB/s
DB Server
Dev
DSS
MB/s
Etc
Dedicated
Shared
Next Generation Benefits for RMAN Merge
•
Scale-out grid of small servers loaded with flash
– 25k write IOPS per node, hash-based data protection
•
Merge bandwidth problem solved
– Any spinning disk source DB, even an all-flash DB
•
Recovery problem solved
– RMAN switch database to copy, fast redo apply
– SolidFire clone for rollback, risk mitigation
•
Resilver problem solved
– All of the devices copy a small fraction of the data
– No per-device bottleneck
Implementing RMAN Merge on SolidFire
•
Put a 10GbE NIC in your database server
–
•
Create SolidFire volumes on a 4-node cluster
–
–
•
See SolidFire best practices doc
Tweak your RMAN scripts
–
–
•
Thin provision for EOL capacity
Define QoS to meet backup window
Access SolidFire using iSCSI and ASM
–
•
1GbE: 12k IOPS of merge, 360GB/hr of full backup
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY DATABASE
RECOVER COPY OF DATABASE
Run a SolidFire clone for each incremental
–
Full automation, can deploy for other use
Legacy Data Guard Standby
Standby
$$$
D
$
25 MB/s
IOPS
DB Server
Redo
D
DB Server
300 B/blk
Primary
87k blk/s!
$$$
Standby
D
Legacy Data Guard Standby Problem
•
Standby is either a duplicate of primary
– Your supplier has a really nice boat
– You drive an old Honda
•
Reduced performance capacity
– You get to drive a new Honda
– You have trouble sleeping at night
•
Need to manage cost and performance
– Your boss gets a boat
Next Generation Solution for Data Guard Standby
Test
Dev
QA
D
IOPS
Data Guard
IOPS
DSS
Etc
Dedicated
Shared
Next Generation Benefits for Data Guard Standby
•
Next generation scale-out architecture
– Economy of shared resources
– Performance of dedicated resources
•
Software defined performance
– Contract for lower performance during standby operations
– Burst capacity during failover/switchover
– Extra performance for Active Data Guard, too
•
Data services make additional copies cheap
– RMAN clone, extra Data Guard copy, SolidFire clone
Implementing Data Guard Standby on SolidFire
•
Put a 10GbE NIC in your database server
– 1GbE: 12k IOPS or 360GB/hr of redo
•
Create SolidFire volumes on a 4-node cluster
– Thin provision for EOL size, set QoS to meet redo apply goal
•
Access SolidFire using iSCSI and ASM
– See SolidFire best practices doc
•
Apply existing process
– Managed recovery, delayed recovery, Active Data Guard
•
Run SolidFire clones for recovery points
– Allow for rollback
Legacy Query Processing
I wish we
could
shorten DB
refresh time
I wish we could
stop worrying
about ad hoc
queries
DB Server
IOPS
I wish we
could add
another index
DB Server
DB Server
DB Server
MB/s
Legacy Query Processing Problem
•
Deploying and refreshing the data warehouse
– Index maintenance
•
Query planning and optimization
– Worrying about I/O transfer size
•
Ad hoc queries
– Can’t plan or tune, need hardware that does not care
•
Spinning disk can’t keep up
– Need a media alternative
Next Generation Solution for Query Processing
Test
Fast DB
refresh!
IOPS
Dev
DB Server
Any index,
any time!
QA
DB Server
DB Server
Ad hoc is
ok!
DB Server
DSS
MB/s
Etc
Shared
Next Generation Solution for Active Data Guard
App Writes
Master
Storage
Consumed
ADG
App Reads
ADG
App Reads
ADG
App Reads
ADG
App Reads
Next Generation Benefits for Query Processing
•
Deploy and refresh with RMAN merge, DG, and ADG
– Low bandwidth use, fast execution
•
Use more indexes
– IOPS for updates, eliminate full table scans
•
Ad hoc queries
– Can’t plan or tune, need hardware that does not care
•
All-flash array
– Fast response time, high bandwidth
Implementing Query Processing on SolidFire
•
Put a 10GbE NIC in your database server
– 1GbE: 12k IOPS of merge, 360GB/hr of full backup
•
Create 8 SolidFire volumes on a 4-node cluster
– Just to start, grow as you need
•
Access SolidFire using iSCSI and ASM
– See SolidFire best practices doc
•
Add/rebuild indexes at will
•
Refresh with RMAN merge or Data Guard
Legacy Test/Dev/QA
RMAN
ADG
Test
Dev
$
$
$
$
Storage
Consumed
Storage
Consumed
Storage
Consumed
Storage
Consumed
QA
Legacy Test/Dev/QA Problem
•
Dedicated storage creates technology islands
– Expensive to maintain, difficult to scale
•
Resources can’t be shared between islands
– Some idle islands, some saturated islands
•
Processing bottlenecks can’t be resolved
– No bridges between islands
•
Everyone is disappointed
– Consume resources you are not using
– Not enough things when you need to consume them
Next Generation Solution for Test/Dev/QA
ADG
Perf
Test
Perf
Dev
Perf
Storage
Consumed
RMAN
QA
Perf
Etc
Perf
Perf
Dynamic Software Performance Control
ADG
Test
Perf
Dev
Perf
Perf
Storage
Consumed
RMAN
QA
Perf
Etc
Perf
Perf
Adjust to any Business Requirement
ADG
Test
Perf
Dev
Perf
QA
Perf
Perf
Storage
Consumed
RMAN
Perf
Etc
Perf
Next Generation Benefits for Test/Dev/QA
•
Shared storage eliminates technology islands
– Cheap to maintain, easy to scale
•
Share resources between applications
– Software defined performance and capacity
•
Resolve processing bottlenecks
– Adjust software defined performance any time
•
Everyone is happy
– Only consume resources you are using
– Enough resources when you need to consume them
Implementing Test/Dev/QA on SolidFire
•
Noisy Neighbor
Noisy Neighbor
Prod
10GbE in your database servers
– 1GbE: 12k IOPS/360GB/hr
QA
•
Create SolidFire volumes
Test
•
Access SolidFire using iSCSI/ASM
Dev
•
Use RMAN or SolidFire to clone
Standby
– FROM ACTIVE DATABASE,
STANDBY, BACKUP
•
Leverage existing procedures
Summary
•
Protect and distribute data with a hash
– Better than RAID, mandatory at scale
•
Deploy flash with shared scale-out architecture
– Software QoS control guarantees application throughput
•
Use flash for backup, standby, DSS, test, development, and QA
– Better, faster, and cheaper, deduplication and shared economics
•
Additional information (papers, videos, etc.)
– http://www.solidfire.com/solutions/database/oracle
1620 Pearl Street,
Boulder, Colorado 80302
Phone: 720.523.3278
Email: [email protected]
www.solidfire.com