SSD với Oracle

19

Chúng tôi đã xem xét việc sử dụng SSD với Oracle để tăng tốc quá trình di chuyển thử nghiệm của chúng tôi. Hiện tại phải mất 12-18 giờ để hoàn thành quá trình di chuyển, giảm khối lượng dữ liệu (rõ ràng chúng tôi cũng đang thực hiện nhiều điều chỉnh hiệu suất). Chúng tôi đã có một số hộp linux giá rẻ chúng tôi đang sử dụng để chạy và phân tích khác nhau.

Chi phí SSD trực tiếp từ Dell là nghiêm ngặt. Tôi đã tự hỏi nếu có ai có kinh nghiệm sử dụng SSD tiêu dùng (chẳng hạn như những cái rất quan trọng / Micron).

Tôi nhận thấy hỗ trợ TRIM sẽ là một vấn đề trên Linux (sử dụng Centos). Có ai đã sử dụng chúng trên Windows 7 để chống lại điều này chưa?

oracle performance

— Stuart Brock
nguồn

1

Chúng tôi đã kết thúc việc thêm SSD cho các chỉ mục và không gian bảng và tách hai cái trên chúng. Chúng tôi đã không có được bước nhảy tốc độ lớn mà chúng tôi hy vọng. Giống như nhanh hơn 10-15% cho các lần di chuyển của chúng tôi, nhưng trong trường hợp không có bất kỳ tùy chọn nào khác là trình tiết kiệm thời gian tốt (chuyên gia điều chỉnh Oracle của chúng tôi đã thả lỏng DB). Cảm ơn tất cả các ý kiến. Chúng tôi đã sử dụng SSD quan trọng, cung cấp hiệu năng khá tốt với giá tốt và vẫn không có vấn đề gì. Chúng tôi cũng chấp nhận họ sẽ mệt mỏi và để mắt đến họ (và các bản sao lưu đa dạng)! Cảm ơn tất cả các ý kiến. Stuart.

— Stuart Brock

6

Dưới đây là vấn đề lớn nhất mà tôi thấy với SSD và cơ sở dữ liệu:

Lỗi SSD
- Nó xảy ra thường xuyên hơn tôi muốn; thường trong vòng một đến hai năm với việc sử dụng bình thường và nhanh hơn nếu đọc từ / viết thành nhiều. Điều gì xảy ra khi bạn gửi lại các tập tin làm lại, nhật ký và dữ liệu của mình vào ổ SSD? Rất nhiều bài đọc, và rất nhiều bài viết. Kết hợp xấu, IMO.
SSD "chữa tất cả"
- SSD là tốt khi nói đến tốc độ đọc, vâng. Chúng thật tuyệt khi khởi động từ hệ điều hành hoặc khởi động chương trình từ đó. Nhưng người ta không nên cho phép SSD trở thành bản sửa lỗi để tối ưu hóa toàn bộ. Tôi chắc chắn là bạn không, vì bạn có thể sẽ thử mọi cách có thể để di chuyển diễn ra nhanh hơn, nhưng đôi khi SSD có thể giống như một chén thánh để tránh một số vấn đề khó khăn hơn khi tối ưu hóa. (Theo nhiều cách tương tự có thể nói về việc ném thêm phần cứng hoặc bộ nhớ vào một vấn đề. Đôi khi, tốt hơn là tối ưu hóa vấn đề hơn là ném nhiều phần cứng vào nó.)
R / W không khớp
- Đọc được nhanh chóng.
- Viết không nhanh như đọc (mặc dù thường tốt hơn so với ổ cứng)
  http://en.wikipedia.org/wiki/Solid-state_drive
- Như vậy, SSD thực sự chỉ có ý nghĩa tốt đối với phương tiện khởi động (như HĐH, thực thi db, v.v.)
Mặc cân bằng và bảo mật
- Nếu bảo mật là bất kỳ mối quan tâm nào, thì mức độ hao mòn trong ổ SSD của bạn sẽ khiến nó không thể xóa sạch ổ đĩa và chắc chắn rằng nó đã bị xóa sạch. Hai, ba và nhiều lượt vượt qua thậm chí sẽ không làm điều đó và sẽ luôn có cơ hội một phần dữ liệu của bạn vẫn có thể lấy được.

— Kerri Shotts
nguồn

Bạn vẫn có cùng quan điểm trong năm 2019?

— TrojanName

7

Tôi chưa thấy câu trả lời nào cho câu hỏi của bạn và trong khi tôi không có bất kỳ kinh nghiệm nào về việc sử dụng ổ SSD cấp tiêu dùng với cơ sở dữ liệu, tôi nghĩ câu hỏi sau đây trên ServerFault có thể hữu ích:

/server/69037/configuring-sql-for-optimal-performance-ssd-or-hdd

chỉnh sửa: Tôi tìm thấy bài viết sau đây gần đây và nghĩ rằng tôi sẽ thêm nó vào câu trả lời của tôi. Nó nói về việc sử dụng SSD với SQL Server, nhưng tôi nghĩ một số yếu tố được thảo luận cũng có thể hữu ích cho các DBA của Oracle.

http://technet.microsoft.com/en-us/magazine/hh334997.aspx (Giảm I / O, Tăng hiệu suất)

— Jeff
nguồn

5

SSD có thể làm cho việc đọc dữ liệu nhanh hơn.

Viết sẽ không nhanh hơn. Thậm chí đừng nghĩ về việc đặt redo lên SSD vì chúng chỉ được ghi vào. Để tăng tốc độ ghi vào làm lại: thêm nhiều ổ đĩa và sọc chúng. Redo được viết tuần tự để thêm nhiều trục chính giúp cải thiện thông lượng ghi, cho đến khi bạn đáp ứng giới hạn bộ điều khiển.

Kiểm tra di chuyển đang làm gì? Nó sử dụng mã thủ tục hay nó sử dụng các bộ?

Nếu sử dụng mã thủ tục, hãy chắc chắn thực hiện các hoạt động hàng loạt. Bộ là tất cả luôn luôn nhanh hơn.

— tôi
nguồn

1

Bạn có nguồn cho một điểm chuẩn hiển thị tốc độ ghi kém hơn trên SSD, đặc biệt là với cùng số lượng phân loại không? Tôi hiểu rằng SSD cũng nhanh hơn khi ghi, nhưng sự khác biệt không quá lớn như khi đọc.

— Leigh Riffel

@Leigh - Điều đó đúng nhưng điểm thực sự là lợi thế lớn hơn đáng kể đối với io ngẫu nhiên so với tuần tự . Tôi nghĩ thật công bằng khi nói rằng SSD vẫn chỉ dành cho nhu cầu iops ngẫu nhiên cao.

— Jack Douglas

1

Chúng tôi đã thực hiện một số thử nghiệm với thẻ f5100 trên hệ thống M5000, nơi chúng tôi đã cố gắng sử dụng các đĩa flash làm bộ đệm thứ cấp cho zfs, dành riêng cho các tệp và sga mở rộng. Đọc rất nhanh, viết chậm, so với những gì chúng ta đã làm với SAN. (một số hộp EMC). Theo ghi nhận, nhật ký được viết tuần tự. Đĩa được làm cho loại io này, khi sọc.

— ik_zelf

2

Tôi đã trao đổi ổ cứng cũ của mình cho SSD SSD 512 MB quan trọng để thực hiện kiểm tra trên cơ sở dữ liệu lớn của Oracle.

Tôi chạy oracle 10.2 trong Windows 7 trong VMWare.

Hiệu suất thay đổi thực sự ấn tượng. Nhập và xuất cơ sở dữ liệu và truy vấn SQL nhanh hơn nhiều.

Tuy nhiên, thỉnh thoảng tôi cũng gặp một lỗi lạ:

LRI 2012-06-18 18: 18: 14,177: Lỗi khi thực hiện truy vấn
java.sql.SQLException: ORA-01578: Khối dữ liệu ORACLE bị hỏng (tệp # 6, khối # 1646317)
ORA- 01110 : tệp dữ liệu 6: 'C: \: ORACLE \ SẢN PHẨM \ 10.2.0 \ ORADATA \ DUNE \ WEBDATA02.DBF '

Tôi chưa bao giờ gặp vấn đề này với cùng một VM trên cùng một máy với ổ cứng.

Sau khi chạy DBV trên tệp, không có gì được đánh dấu là bị hỏng.

Tôi chưa tìm thấy gì về vấn đề này.

— svett
nguồn

Đừng nhận ra lỗi đó nhưng tôi đã quên đề cập rằng việc nhập khẩu đã được tăng tốc một cách ồ ạt bởi SSD. Đó chỉ là các cuộc di cư chỉ tăng tốc 10 - 15%. Vì vậy, cảm ơn vì điều đó.

— Stuart Brock